I'm running this command
w_icrcom.exe j11 hola
from a command prompt and it is working properly, the exe is running using the arguments.
But when I'm doing the same from a C++ program the w_icrcom.exe is behaving differently. I'm getting an error saying that "abnormal program termination". This though is happening only when you pass arguments to 'w_icrcom.exe'.
It seems to me, that when I execute a command everything is fine, but when some other program is trying to execute the same command it doesn't work and I'm getting the "abnormal program execution" error.
I tried the same set up on ShellExecute calling the notepad.exe and passing arguments and it worked fine. Is there any logical explanation on this issue?
string test_var = ("j11 hola");
ShellExecute(0, "open", "C:\\Users\\PC\\Desktop\\My First\\connect\\bin\\w_icrcom.exe", test_var.c_str(), 0, SW_SHOW);
The next to last parameter of ShellExecute is the 'working directory'. It might need to be set to whatever is the current directory in the cmd prompt that is working.
Related
As the title may suggest, i am trying to open a .bat file via "ShellExecute" function.
It works with very basic .bat scripts, such as "hello world" ones, but won't work with others containing commands for running game servers.
For example, here is a batch script for a "Killing Floor 1" server:
ucc server KF-Mountainpass.rom?game=KFmod.KFGameType?VACSecured=true?MaxPlayers=6?GamePassword=genrl -log=server.log
PAUSE
Please note that this batch works perfectly when manually clicking on it, but gives the following error when opened via ShellExecute:
"ucc" is not recognized as an internal or external command, operable program or batch file.
I have also tested on other batch files for other game servers, having the same result.
So, here is a list of what i have tried so far, and did not work:
ShellExecute(NULL, "open", "cmd.exe", "C:\\windows\\system32\\cmd.exe /C C:\\Cartella_Server\\Server_KF1\\System\\KF_Server_Launcher.bat", NULL, SW_SHOW);
ShellExecute(NULL,"open", C:\\Cartella_Server\\Server_KF1\\System\\KF_Server_Launcher.bat", NULL, NULL, SW_SHOW);
ShellExecute(NULL, "open", "cmd.exe", "/C C:\\Cartella_Server\\Server_KF1\\System\\KF_Server_Launcher.bat", NULL, SW_SHOW);
Is there any solution to this?
Thanks in advance for your time :)
It is because the script is loading inside the directory of cmd.exe
Why? Because you didn't fill the working directory field.
Have a look at the 5th parameter of ShellExecute:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx
Most likely, the ucc program is in the same directory as tha launcher script. So it works when you click on it, because your current directory is one with the file, but when you run your program your current directory is different.
Solution - provide proper directory in fifth ShellExecute argument, as per https://msdn.microsoft.com/en-us/library/windows/desktop/bb762153(v=vs.85).aspx
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.
I try to create a simple UI which runs a command prompt in the background (but the windows console must not disappear) while clicking on each button, resp.
But before, I try something like system("start dir"); to see if the button works.
Here is the problem: when I click on the left button the windows console appear and don't exit unit I close it. But this only work with system("start dir");. If I change dir to ipconfig (or another call-function) the windows console will appear for a second and the exit. I tried something like system("PAUSE"); or getch(); etc, but it doesn't work.
Why does this command work with dir but not with another command?
There is a fundamental difference between DIR and IPCONFIG, the DIR command is built into the command processor (aka shell), IPCONFIG is a separate program stored in c:\windows\system32.
When you type START /? at the command line then you can see why it treats them differently:
If it is an internal cmd command or a batch file then
the command processor is run with the /K switch to cmd.exe.
This means that the window will remain after the command
has been run.
If it is not an internal cmd command or batch file then
it is a program and will run as either a windowed application
or a console application.
The alternative is to ask the command processor to execute the command and exit afterwards. You do with the /c option:
system("cmd.exe /c dir");
Or simpler yet, since system() automatically passes off the job to the command processor:
system("dir");
Just stop using start :)
I’ve produced a C++ program in Eclipse running on Redhat, which compiles and runs fine through Eclipse.
I thought that to run it separately to Eclipse you use the build artifact which is in the directory set via the project’s properties.
However this executable doesn’t run (I know it’s an executable as I’ve set it to be an executable via the project’s properties and it shows up as such via the ls command and the file explorer).
When attempting to run it using the executable’s name, I get the error:
bash: <filename>: command not found
When attempting to run it as a bash file:
<filename>: <filename>: cannot execute binary file
And when running it with "./" before the file name, nothing happens. Nothing new appears in the running processes and the terminal just goes to the next line as though I’d just pressed enter with no command.
Any help?
You've more or less figure out the first error yourself. when you just run <filename> , it is not in your PATH environment variable, so you get "command not found". You have to give a full or relative path when to the program in order to run it, even if you're in the same directory as the program - you run it with ./<filename>
When you do run your program, it appears to just exit as soon as you start it - we can't help much with that without knowing what the program does or see some code.
You can do some debugging, e.g. after the program just exits run echo $? to see if it exited with a particular exit value, or run your program using the strace tool to see what it does (or do it the usual way, insert printf debugging, or debug it with gdb)
I am trying to compile my first c++ file on windows with the g++ compiler...
My cpp file is the following -
#include <iostream>
using namespace std;
int main ()
{
cout << "Hello World!";
return 0;
}
I type in this on command prompt to get to the directory
cd C:\Users\Mark
Then to compile my program I do
g++ hello.cpp
It creates a file name a.exe (default) but when I click on it the command prompt quickly flashes open then it's gone.
What did I do wrong? It should say Hello World! on the prompt and stay there, right?
What you did looks correct, but if you start the program by double clicking it in Windows, the new command prompt will be closed once it is finished. Since you already have a command prompt open for compilation, try to start the program from there, too:
g++ hello.cpp -o hello.exe
hello.exe
That's just normal Windows behavior of executing a command-line file from the UI -- as soon as the program exits (immediately in your case), the prompt window closes.
Running it from the command line will keep it up. To do that, Start > Run > cmd, then cd to the directory, then type a.exe.
Alternatively, you can wait for input from the user to keep the window open. That's fine for testing, but nobody who actually executes programs from the command line would want to have to hit a key to stop a program from running, when it should exit on its own correctly.
you didnt do anything wrong. There isnt a readline or anything at the end of your program, so when it is finishes executing it closes. Add a read character at the end of the program to make it wait for input to terminate.
You did everything right. Whether or not the command prompt stays open has nothing to do with your program. The command prompt is itself a program, and its default behavior is that when it launches in response to the execution of a console application, it closes immediately when the program is finished.
What you should do is launch the command prompt yourself and then run the program from within it, rather than launching the program by double-clicking its icon.
Do not fall into the bad practice of adding a call to some sort of pause function, or waiting for input at the end of the program. You should not get in the habit of hard-coding work-arounds for unwanted behavior of a particular shell into your application. Just use the shell the right way to get the behavior that you want.
The prompt has nothing to do with your program or the language. It has to do with your OS.
Your program should be run from the command line, which will (obviously) leave the command window up when it's finished.
There are tricks to make it stay up if you really want, but these are just tricks, and not necessarily good practice. One would be:
int main()
{
std::cin.get(); // waits for enter
}