September 9th, 2003, 09:26 AM
Console app starts by explorer not by cmd line
I have made a console application using VC++ 6.0 and it runs fine (I sware ! :D) when I double click on it.
But I need it to run through command line and it doesn't ! :mad:
It seems it stops as soon as it has been launched. :confused:
No error, no message... :rolleyes:
Anyone can help ?
Last edited by bernardb; September 11th, 2003 at 08:26 AM.
September 9th, 2003, 09:37 AM
Open up a shell/cmd & execute your app.
Or at the end of your code put something like...
September 9th, 2003, 09:40 AM
'Splain. Usually the complaints are the other way around. They try to run the program within the VC++6 IDE and it closes immediately so they never see their output.
First, what do you mean by "it runs fine ... when I double click on it"? You've made it a shortcut on the desktop or what? Since we only single-click on the IDE toolbar button to run the app, that can't be what you're talking about.
And what does the program do when it does run fine?
And exactly what indications are you getting/not getting when you try to run it from the command line? Absolutely no output and the prompt reappears immediately? A message of "Bad command or filename"? Absolutely nothing appears to happen, including that the prompt does not reappear?
What basically are you trying to do, I/O-wise, in your app? Are you using printf's or cout's (not knowing whether you're using iostream or not) or something else?
September 9th, 2003, 09:43 AM
I have already tried this.
It changes nothing
I've tested this but still have the same problem :confused:
Last edited by bernardb; September 9th, 2003 at 09:49 AM.
September 9th, 2003, 09:48 AM
First, many many thanks for your help guys !
It runs in VC++.
It runs out of it when I doubleclick on the program through the windows explorer
When I use the command line or runs it through a batch file (.bat file), it fail.
It populates a database from another one.
Aboslutely nothing is done.
The command prompt appears immediatly after.
No message, no error, no waiting time...
The program is meant to get data from one database and update the data of another one.
It produces some logs, connect to some DB.
But this runs fine through the explorer... :rolleyes:
I'm a bit lost
September 9th, 2003, 10:50 AM
OK, where does this program reside? I am assuming that it is still in the myproject\debug or myproject\release directory where VC++6 places the .EXE file that it builds.
I also assume that you have navigated Windows Explorer to that directory and that you are double-clicking on the .EXE file and not on a shortcut to it. This may or may not be a key assumption -- I will need to test what directory Windows assumes you are in when you launch an app through Windows Explorer.
Now, at the command line, what directory are you in when you try to run the program? Are you in the same myproject\debug or myproject\release directory or are you in a directory other than the one the .EXE file is in? Of course, running a program in another directory requires that either you use a directory path to indicate where the .EXE is or that the .EXE's directory is in the searchpath PATH environment variable.
Now, if you are in a different directory than the .EXE file is in, how do you tell it what files to work with? Do you include an explicit directory path to those files or are they assumed to be in the current directory? If the latter case, then that could be the problem.
For debug purposes, display an error message to stdout or stderr (both go to the console) if you fail to open or find the files.
I just confirmed that when you run a program from the Windows Explorer, it assumes the .EXE's directory to be the current directory.
Test consisted of a program that would try to open a file in its current directory and report either success or failure.
Succeeded when run from Windows Explorer and from the command line in the program's own directory.
Failed when run from another directory.
Last edited by dwise1_aol; September 9th, 2003 at 11:04 AM.
September 10th, 2003, 02:00 AM
Thanks for you help.
Very accurate questions, hope they will help get rid of my problem.
In fact, it is in another computer when I launch it.
But, the batch file used to run it, perform change directories so it runs from the inside of the directory (I hope) and looks for any file in this directory.
You are right.
There is no shortcut.
It's standard directory where the .exe reside, I mean, not a directory from VC++. (d:\test\)
And I use CD command to go inside
Isn't CD command enough ?
Yes I assume the files needed (some dlls) are in the same directory.
But, as said sooner, I supposed CD to this directory was enough.
I try this and get back to you.
September 10th, 2003, 02:09 AM
Following the same thinking scheme, I have traced the file paths that I were using and assuming good.
It apperas that, I was assuming that argv was containing the program name but also it's full path.
This seems to be right when launched from the windows explorer but wrong when launching from command prompt after CD commands.
Many thanks to all guys that helped me to find this.
hum... How do I get the current directory path ? :rolleyes:
September 10th, 2003, 02:29 AM
I used '.\' as current dire :)
Thanks again, the problem is solved.
September 10th, 2003, 11:02 AM
Glad to hear the problem's been solved.
The reason I asked about the search path is because relying on that could have placed out you outside of the directory you needed to be in. E.g., your prog.exe is in d:\test\ and it expects files to be in the current directory:
From any arbitrary directory (eg c:\):
would run but fail to open the files
If d:\test is in the search path, then
would effectively do the same as above, fail to open the files.
Similarly, I asked about it being a shortcut because when you set up a shortcut, you specify what the working directory will be. So that would have made the Windows Explorer launch work. As it turns out, launching an EXE automatically makes the working directory the same as the EXE file's.
Curious. Testing with both gcc (MinGW Windows port) and Visual C++6, I found the argv contained the fully qualified filename of the program; i.e., full path and file name, including extension. And I get the same results with VC++6 whether running from the IDE, Windows Explorer, or the command line.
In case the OS has a bearing on this (which is likely), I ran that test on Win98SE. I'll try it on WinME and Win2k when I get home in about 10 hours.
From the command line just type cd. But I assume that you mean from within the program. Look in the help file for Directory Control: _getcwd, _getdcwd.
September 10th, 2003, 11:20 PM
I ran the experiment at home.
On WinME running the test program from the VC++6 IDE and from Windows Explorer and from the command line, argv contains the fully-qualified filename of the program, full pathname and all.
On Win2k running the test program from the VC++6 IDE and from Windows Explorer, argv contains the fully-qualified filename of the program, full pathname and all. However, from the command line all I get is the filename with no directory path. Actually, if the program is in the current directory or on the searchpath, all I get is the filename. If I have to provide a path to the program file, then that path is included.
On Win95/98/ME the command-line shell is COMMAND.COM. On WinNT/2k/XP the shell is CMD.EXE. So it looks like the two shells handle argv differently. The IDE and Windows Explorer probably attach the full directory path before invoking CMD.EXE, which is why they work while the straight command line doesn't.
Thanks for raising the question. I'll have to remember that odd behavior, especially since the well-behaved Win95/98/ME has become an evolutionary dead-end in favor of the ill-behaved NT line.
Having to type in the entire long-long-long directory names without benefit of short-name alternatives is a pain. I wish they would catch on and allow Linux-style wild-carding of directory names.
September 11th, 2003, 02:13 AM
I'm on win NT4 and also making CD before running the program.
So it confirms your tests. :)
September 11th, 2003, 07:57 AM
In the future please use an acceptable subject title. You can refer to the sticky thread at the top of this forum for more information on how to post a question.
September 11th, 2003, 08:04 AM
Can you suggest to me an 'acceptable' title for this thread ?
I'm moderator of a forum and knows the problem of titles but after thinking a moment on how to put a good title, I didn't find one better... :confused:
September 11th, 2003, 08:14 AM
console app does not launch via cmd line
app starts by explorer by not cmd line