I develop a c++ CGI program that runs under Windows and Linux.
This program calls another program like this:
system("otherProgram.exe arguments");
I also tried:
spawnl(_P_WAIT, "otherProgram.exe", "argument1", NULL);
This works fine in my debugger and in my Virtual Machine, but on my test server it doesn't work.
The system call returns -1.
Any ideas why?
This is likely a permissions issue. By default your CGI application will be run as if by user nobody. The program you want to launch should be executable by "nobody".
Is the directory containing "otherProgram.exe" in one of the directories in your PATH environment variable in the test box? That is, does your operating system know how to find that program?
Related
I am new to Lua programming language. I installed Lua for Windows v5.1.5-52. I want to use luacom library to run shell script. Here is my code,
local luacom = require('luacom');
local shell = luacom.CreateObject("WScript.Shell")
shell:Run ('echo 123', 0)
which throws the following error:
lua: COM exception:(.\src\library\tLuaCOM.cpp,398):The system cannot
find the file specified.
I looked for tLuaCOM.cpp file, but could not find it, not even folder src. Though I found luacom.dll in clibs folder.
Is there any workaround with this problem?
tLuaCOM.cpp is a luacom source file, so it's probably not on your PC, except you've build it yourself.
The error comes from one of the calls - either CreateObject() or Run.
The Run Method (Windows Script Host) helps says that it starts processes:
The Run method starts a program running in a new Windows process.
but echo is a shell command, not an executable, so you have to start an instance of the Windows command interpreter and pass your command like:
shell:Run('cmd /c "echo 123"')
I'm trying to run an executable, generated from C++ code, in Matlab.
To do this I use the command
system('unset LD_LIBRARY_PATH; /home/Documents/ServerFolder/ExecutableFiles/program_23 argument');
where program_23 is the executable generated by the C++ code.
When I do that in Ubuntu, it works perfectly fine.
The problem arise when I do that from a SSH server (i.d. calling Matlab from a server, but running the exact same script that works in Ubuntu).
In particular, if I add
[status,cmdout] = system('unset LD_LIBRARY_PATH; /home/Documents/ServerFolder/ExecutableFiles/program_23 argument');
I can see that status is different from 0, meaning a failure of the system command.
Does anyone have any idea on how to make this work?
Thank you
p = subprocess.Popen([executable_file])
This is only code that I am using to run the python subprocess. However, it has unknown issue that cause my program cannot open the executable file as expected.
executable_file is one file link (PATH) that locate executable program.
Ex. C:\Users\SharkIng\Dev\WhatEverSystem\Builds\Windows\program-123456789-123456789.exe
The python subprocess.Popen should run the program. However, sometime it works and sometime it is not (I did not change any code between this two situation)
OS: Windows 10
Python: 2.7.*
Error: [Error 2] The system cannot find the file specified
BUT: It is working if you manually run subprocess.Popen([executable_file_path_string]) (with same file and path) it work.
WHY this happen?? Is that because some problem with Windows Python? or it is because my setting mess me up?
UPDATE: It is not some reason such as NOT FULL PATH. I can have it working with exact same code. If I ran same code in a python shell, by typing each line of code. It works. But if I put exact same code in a .py file and run it with python file.py, it showing the error
UPDATE 2: Another team member have same error with Windows 7 and Python 2.7.* This code used to work this morning. AGAIN I didn't change anything. That is way I am asking if it is unstable.
There is no problem with subprocess. If you want to run a specified executable, you need to give the full path to that file. The most likely reason you're seeing variable behavior is that sometimes you're in the directory with the .exe, and other times you're not.
This is a weird one for sure.
If I open a command prompt window directly (searching cmd in start, right click > open command window here, cmd within bat file, etc....) all commands entered run perfectly fine.
If I open a command prompt window from within my C++ application (system("cmd"); or QProcess::startDetached("cmd"); etc....) the commands I enter throw errors.
Here are a few commands that don't work in the cmd opened from my app:
vssadmin delete shadows /all
vssadmin list shadows
wmic
shadowcopy
and so on... I get Class not registered and Initialization failure errors all around. Anything to do with shadow copies isn't working at all. But again, the weird thing is, those same commands work perfectly fine when cmd was opened traditionally (not from a program). Both instances of cmd have admin privileges.
So my question is, how come the way I open cmd affects whether or not some commands work? Everything I can see says there should be no difference.
32-bit applications running on WOW64 will be put under file system redirection. Therefore if your app is a 32-bit one, the call system("c:\\windows\\system32\\cmd.exe"); will be redirected to C:\Windows\SysWOW64\cmd.exe and 32-bit cmd will always be invoked. You have some solutions:
Use system("c:\\windows\\sysnative\\cmd.exe"); to access the real system32 folder and get the 64-bit cmd
Turn off file system redirection explicitly (should be avoided in general)
Or better compiling it as a 64-bit app.
Hey guys,
I have written a program to act as a keyboard backlight controller for my MacBook Pro that runs Arch, just like there is natively in OS X. The program itself works great, but the rc.d script I provide with the Arch program package, doesn't seem to open the program correctly ... or so I think.
The source to the Arch package can be found here (rc.d script and PKGBUILD file). I have added "mbpkbdbacklightctl" to the line with daemons in my /etc/rc.conf.
What happens is, that upon start up, I see that the rc.d script starts the program is started without errors, and the backlight on the keyboard is lit on which means the program is also run properly, but then when gdm starts to log in to gnome, the program seems to already have been terminated. I havent been able to find any errors logged, but the program will turn off the backlight if no keyboard or mouse events are registered in 20 or more seconds and turn it back on when one it registered, and this doesnt happen at the gdm and neither in gnome. Also, when I reach gnome and do a pidof -o %PPID /usr/bin/mbpkbdbacklightctl, it returns nothing indicating that the program has been terminated. When gnome is started, I have to restart the rc.d script to make things run properly.
I cant seem to get a grasp on what happens to the program since it is terminated.
The source to the program can be found here, though, I believe that the error is in the rc.d script and that it might not start the program properly for it to "survive" through gdm start-up.
Any ideas to what can be going on?
Regards,
Chris Buchholz
If you read the source code for mbpkbdbacklightctl.cpp you will see these lines:
95 std::string the_display = ":0.0";
96 Display *x11_display = XOpenDisplay(the_display.c_str());
97 if(x11_display != NULL) {
So it will fail if there is no active X server, this means that you have to start this script after X session starts. So you have to put your script under /etc/X11/xinit/xinitrc.d