4

I'm writing C++ console programs. After compilation, when I run the program from my file browser, cmd.exe automatically closes such that I can't see my programs output.

The only way to work around this I've found is to run the program from inside cmd.exe

Is there anyway to keep cmd.exe open after a program finishes running?

Is there a setting I can change somewhere? I don't want to run a batch script with cmd.exe /K

Thanks!

[Edit] Don't know if this matters, but I'm on Vista x64

hwrd
  • 2,134
  • 6
  • 29
  • 36

5 Answers5

7

You can setup a shortcut with the /K switch when launching cmd.exe to have it not terminate after running a given command:

 cmd.exe /K YourProgram.exe
Doug T.
  • 64,223
  • 27
  • 138
  • 202
6

Have your application ask for a keypress before exiting - that's the easiest fix!

Chris Harris
  • 4,705
  • 3
  • 24
  • 22
  • I've thought of that, but I wanted to know if I could change to keep cmd.exe open globally. Is there anything I can do to cmd.exe? – hwrd Jun 07 '09 at 22:12
  • 3
    Not since the Windows 98 times, no. You can put a batch files around it which essentially just runs your program and "pause" after that. Or you could put a new entry in the context menu pf a program with the command line cmd /c "%1 & pause". – Joey Jun 07 '09 at 22:18
  • Also, that's what you usually did in dos days with an ide, otherwise, it just switched back to the debugger... – SurDin Jun 07 '09 at 22:40
  • 3
    Note that if you're running your program directly from your file manager, cmd.exe is not involved in this at all. There's no way to stop cmd.exe from automatically closing because it's never been opened in the first place! – Spire Jun 07 '09 at 23:38
  • 1
    Spire's right -- cmd.exe is just a program that runs using a the CONSOLE subsystem. You can choose which subsystem a program you compile will use with the /SUBSYSTEM flag to LINK.EXE: http://msdn.microsoft.com/en-us/library/fcc1zstk(vs.71).aspx – j_random_hacker Jun 08 '09 at 05:50
  • @Johannes: I was about to suggest "&&" instead of "&" as I hadn't heard of the latter, but sure enough, your "&" is better -- it will run the second command even if the first fails. I learnt something :) – j_random_hacker Jun 08 '09 at 05:57
  • 1
    You don't want to keep CMD.EXE open globally anyway. That's bound to affect other programs which expect it to close. – MSalters Jun 08 '09 at 08:10
2

I've always been a fan of just creating a batch file that calls you're program and then calls pause

Prog.exe Pause

This will give a nice "Press any key to continue..." prompt, it's simple and doesn't require modification of program.

Arelius
  • 1,216
  • 8
  • 15
  • I like adding an autohotkey script to have a shortcut that launches the batch file. Even easier. – toto Jun 08 '09 at 00:32
2

As the last line of your main() function, you can add this line:

system("PAUSE");

Also, make sure to #include <stdlib.h> to declare the system() function. This will make the console pause. However, if your program is run from inside cmd.exe, this will still pause, which may be undesirable.

Adam Rosenfield
  • 390,455
  • 97
  • 512
  • 589
  • system() calls are bad. Type that into Google for the long list of reasons that wouldn't fit in this comment. – Gordon Jun 02 '10 at 14:45
1

I know you asked for how to do it via a file browsers, but in case other people are interested in the same problem but through visual studio:

It's best to set a breakpoint right before your program ends.

Then you can deploy your exe and you can be sure that you won't forget to remove the asking for input. It's also better then asking for input because it takes a lot of time to comment out and back in the asking for input.

I think it is best not to ask for input and to instead start your program from a launched command prompt.

Brian R. Bondy
  • 339,232
  • 124
  • 596
  • 636
  • A breakpoint? Like _asm int 3? That's a manly keypress right there! – toto Jun 08 '09 at 00:31
  • No... Like a red dot in the VS IDE. One that does not inject code into the compiled .exe. – Brian R. Bondy Jun 08 '09 at 00:48
  • But the problem was that the console went away too fast when running the program from the file browser. That is, from Windows Explorer. Programs started by Explorer are not subject to breakpoints because they're not being debugged. – Rob Kennedy Jun 08 '09 at 18:33
  • @Rob Kennedy: I see, I modified my answer to indicate that this only applies to when running it from visual studio. – Brian R. Bondy Jun 08 '09 at 18:48