sytem("pause") whats the big deal?

[mirhagk]

Yes there are alternatives, such as using conio.h _getch. But WHY???? conio.h is still platform specific, and DON'T TELL ME IT'S CUZ IT'S SLOW!!!!!!! IT'S A FREAKING PAUSE COMMAND, IT'S SUPPOSED TO STOP SO WHO CARES!!!!!!!!!!

I agree system("pause") shouldn't be used in a distrubuted exe simply because they may have defined their own PATH variable that overrides system.

But it's a great way to pause the program at the end to see the output while debugging, as it requires only one line of code. And it's a great way to introduce the programmer to system commands. As you can get them to use this, and then be like "BTW, type that into the command prompt" and then you can teach them that the system() command is basically an interface to command prompt, so you can do things from system that you could do from the command line.

Yes don't use it for final projects, but who cares for testing and learning purposes.

Sorry, I just hate reading things where people argue that system("pause") is too slow. Im like *blank stare*

[DemonWasp]

Consider: http://www.gidnetwork.com/b-43.html

Most of the arguments are that you shouldn't have to explicitly pause your program to let the user see output anyway -- it should just be sitting there in the terminal / terminal emulator in your IDE.

Another valuable argument is that it isn't cross-platform, it isn't widely used, and it requires that you load up more libraries at runtime.

If you use platform specific things, you are (generally) limiting yourself for little or no reason. You will eventually find that you want your code to run elsewhere (or, one of your customers will) and then you're up the proverbial creek. If you wrote it right in the first place, you wouldn't have any trouble at all.

Plus, if you write your code in a cross-platform manner, that means that anyone can contribute to your project. If your friend wants to work on code that has system("pause") sprinkled through it, they will first have to fix all those invocations before they can get any actual work done. Better to do things right the first time, as much as possible, to avoid bigger problems later.

[bbi5291]

mirhagk @ Mon Feb 21, 2011 1:10 pm wrote:

And it's a great way to introduce the programmer to system commands. As you can get them to use this, and then be like "BTW, type that into the command prompt" and then you can teach them that the system() command is basically an interface to command prompt, so you can do things from system that you could do from the command line.

I really don't think this is a valid argument, anyway. For example, could I not claim using the same logic that 'cout << "Hello, World!" << endl;' is a great way to introduce the programmer to operator overloading? (I think just about everybody would agree that it's not.)

There are times when system() may be exactly what you need --- it's a platform-independent way to run commands, and even if you're just coding for one platform, it can still be more convenient (e.g., on Linux, it's easier than the 'if(!fork()) {exec(...);}' structure), but pausing the program after execution shouldn't be one of them. A good example... may indeed be a good way to introduce something, but a poor example is not.

[Dan]

Part of the problem is most new programers don't acuatactly understand what the system command is or what it is doing in this case.


Whould you do this to print?

system("echo Hello World");


Whould you do basic math and output it like this:

system("set /a ((10 + 5) / 2) * 10");


You might as well be making a batch script if you are going to be calling system for trival things allready implmented in C.


Also calling OS specific commands with system may not even be compatable between different versions of the same OS or even work on all computers with the same version of the OS but with differnt programs installed or directoires on it's path.

Consdier the following example:

system("telnet compsci.ca");

On an xp system this would likely open up the comand line telnet client and connect to compsci.ca. However on windows vista or 7 it will likely produce an error unless a telnet program was installed by the user. Also consdier that if the user did install thier own telnet command that this could produce an unknow result. Maybe my telnet command just prints "Hello World", maybe it allways retruns a 5, etc.

Now lets consider the seucrity issues with system. Lets say you are making a program that will be run as the adminstator user on a Windows system. Lets also assume that this program calls the program good.exe which is know to be a safe program or even part of windows. Consdier what happens if the permisons are not set correctly on good.exe or their is some unrealted securtiy expolite that allows a limited user to replace the contets of good.exe with their file bad.exe. You have effectively given that limited user full access to the system as your program will call on good.exe, which has now been replaced with a program from the limited user that will be run at the adminstatior level. It does not even nessarly have to be a permsion or security issue that lets you write to good.exe but simply changing the path setting that is being used when the system comand is called, or droping the file into a directory on the path with the name good.exe maybe enoguh to redirect it to a malicious program.

Their deftaly are valid use cases for the system command. However you need to take into consideration serveral factors befor throwing it into your code. Do i need this program to to be platfrom independent? If so is the command i am calling platform-independent? Will the users of this program have this command installed? Is it added to the system path or do i need to call it directly? Will the comand produce the same results on all of the systems i want to run it on? Do i care about the return code, will it be the same on all systems? And most inmportaly, is their a better way to do this from with in C?

Just throwing "system("pause")" at new programers with out any explaintation other than it pasues it program is going to lead to bad programing partices, ignorence about how their program aucatactly works and hinder their learning of the proper way to acomplish tasks in C.

[rdrake]

I'll bite.

mirhagk @ Mon Feb 21, 2011 1:10 pm wrote:

Yes there are alternatives, such as using conio.h _getch. But WHY???? conio.h is still platform specific,

Truth.

mirhagk @ Mon Feb 21, 2011 1:10 pm wrote:

and DON'T TELL ME IT'S CUZ IT'S SLOW!!!!!!! IT'S A FREAKING PAUSE COMMAND, IT'S SUPPOSED TO STOP SO WHO CARES!!!!!!!!!!

Who told you that?

mirhagk @ Mon Feb 21, 2011 1:10 pm wrote:

I agree system("pause") shouldn't be used in a distrubuted exe simply because they may have defined their own PATH variable that overrides system.

Not only that, but it will only work on Windows computers.

mirhagk @ Mon Feb 21, 2011 1:10 pm wrote:

But it's a great way to pause the program at the end to see the output while debugging, as it requires only one line of code.

Protip: If you use Visual Studio, run the program with CTRL+F5 to get the same behaviour without the pause line. Some of my students showed me that.

mirhagk @ Mon Feb 21, 2011 1:10 pm wrote:

And it's a great way to introduce the programmer to system commands. As you can get them to use this, and then be like "BTW, type that into the command prompt" and then you can teach them that the system() command is basically an interface to command prompt, so you can do things from system that you could do from the command line.

Disagree. One could argue that using the command prompt alone is much faster.

mirhagk @ Mon Feb 21, 2011 1:10 pm wrote:

Yes don't use it for final projects, but who cares for testing and learning purposes.

Quoted for completeness.

mirhagk @ Mon Feb 21, 2011 1:10 pm wrote:

Sorry, I just hate reading things where people argue that system("pause") is too slow. Im like *blank stare*

Who says such things?

Enjoy your meal.

[Dan]

rdrake @ 21st February 2011, 8:39 pm wrote:

mirhagk @ Mon Feb 21, 2011 1:10 pm wrote:

Yes there are alternatives, such as using conio.h _getch. But WHY???? conio.h is still platform specific,

Truth.

If you must do this (which i do not recomened in any way), you should use getchar() from stdio.h for C programs. It's portable and has no crazy system calls. You even get to see what key they hit.

rdrake @ 21st February 2011, 8:39 pm wrote:

mirhagk @ Mon Feb 21, 2011 1:10 pm wrote:

and DON'T TELL ME IT'S CUZ IT'S SLOW!!!!!!! IT'S A FREAKING PAUSE COMMAND, IT'S SUPPOSED TO STOP SO WHO CARES!!!!!!!!!!

Who told you that?

I did not tell him that my self, but it is slow and uses more memoery. You can see the explaination in the link DemonWasp gave: http://www.gidnetwork.com/b-43.html

I think this is more of an arugment aginsted using such calls needlessly than for the pause case in particular.

Quote:

Protip: If you use Visual Studio, run the program with CTRL+F5 to get the same behaviour without the pause line. Some of my students showed me that.

This is exctactly what you should be doing in visual studio rather that adding a pause. CTRL+F5 runs the project without debuging, if you want the same effect with debuging you can just add a break point at the end of your program or there should be an option some where in VS to allways pause at the end. Almost every other modern IDE has a simualr option, and if you are using the command line their is no reason to pause.

I find far to many students get too depdendent on an IDE and end up having no idea how to complie from the comand line or even that their is a differnce between the IDE, complier, etc.


Another issue with system("pause"); or the idea of pausing your program for needless input, is that it makes it much harder to use your program in a bash script, batch script or to call it from another program.



Edit: Any one reading this may want to check out the "Things to Avoid in C/C++" tutorial at gidnetwork.com : http://www.gidnetwork.com/b-56.html

[Xupicor]

If you want a reliable "Pause" function, you should write it yourself. Easy:

c++:

void Pause() {     std::cout << "Press ENTER key to continue.\n";     std::cin.sync();     std::cin.ignore();     std::cin.sync(); }

It will work regardless of OS as long as you can use iostream, it won't fail if you have things inside your input stream buffer (it will clear it though), it doesn't depend on non-standard and old Borland conio.h.

What you should do though is use better IDE, like Visual C++, Code::Blocks, NetBeans C/C++... These three will keep the terminal open for you after the application finished, making the above abomination obsolete.
Or, just open the console (use Console2 terminal on Windows for a nice alternative, you'll be able to set tabs with start-up dirs for convenience) and run your application there. I mean, how hard is that, you type the name once, press <Enter> - and next time you want to run it, just hit <Arrow Up> and follow with <Enter>.
It won't disappear, I promise. No, it's not magic.

Quote:

I find far to many students get too depdendent on an IDE and end up having no idea how to complie from the comand line or even that their is a differnce between the IDE, complier, etc.

Yes, that is somewhat depressing that plenty of novice programmers have no idea you don't really need an IDE to compile things. On various programming boards I can see plenty of confusion about what IDE and compiler is. A number of times those two terms are used as if they are the same thing.

edit:
Also, what if a users machine has a malicious application or script named "pause" (pause.exe, pause.bat, etc) on PATH? You'd happily call it with system() and make it look like your application is doing very naughty things every time it is run. You'd then get a feedback that your application is malicious. You could debug it to death on your machine and yet you would never reproduce the same behaviour, unless you'd get "infected" too.

[mirhagk]

Dan @ Mon Feb 21, 2011 11:02 pm wrote:

if you want the same effect with debuging you can just add a break point at the end of your program

Seriously???? Adding a breakpoint is supposed to be faster? It's supposed to be more reliable? WHAT THE HELL ARE YOU THINKING!!!!!!!!!!!

i'm saying system pause should be used instead of a breakpoint, how annoying would it be to have the program minimize, the IDE jump to your code, and you have to go back and open it up in order to see your output, then go back to the IDE and continue execution for the 0 seconds to return to your code.

Dan, I'm sorry but that's the dumbest thing I ever heard.

My point was that people argue against system pause with the wrong arguments. Like it's too slow. Every article says that, and they are seriously morons.

[TheGuardian001]

mirhagk @ Wed Feb 23, 2011 10:33 am wrote:

Dan, I'm sorry but that's the dumbest thing I ever heard.

You clearly don't read your own posts very often then...

[mirhagk]

I'm sorry, but saying setting a breakpoint is better than using system("pause"). How? That's not based on anything other than one sided hatred towards system("pause), without a reason.

[DemonWasp]

A breakpoint lets you examine program state, including variable values, pointers, and so forth. You can step through your code to see what goes on afterwards.

Using breakpoints avoids polluting your source code with calls to the system and #includes / libraries you don't need.

Using breakpoints lets individual developers pause wherever they want to, rather than where the source says it should pause.

Using breakpoints works better with other debuggers, like gdb, because it doesn't require user input to proceed.

[mirhagk]

but... how is a call to the debugger better to pause exectution to see output, better than a call to the system.

The point is that we don't need to see variables, or other debug info, we need to see the output. And if your seriously saying a breakpoint is better than system pause for just seeing final output, you have something wrong with you.

[Dan]

mirhagk, you either don't understand what a break point is or you are being a troll.

Adding a break point in VS does not acutactly add anything to the source code and is only relvent when ran in debug mode. Who would have though debug mode gives you debuging info, the the horrors!

Your production code would be with out such debuging information and the break point would be irrelevant.

Also way to skip over every other point I and every other post made. If you can't beat them, ignore them?

For example you skiped over the points made in the same paragraph about VS automaticly adding a pasue for you after it runs your code when running the project without debuging. So aprently your outrage is realted to the fact that you want to run your project with debuing but not see any debuging info???

I am done with this topic, the arugments for not using system("pasue") have been layed out for you rather clearly a number of times by serveral differnt posters and you have offered no reasons to use the command over say getchar().

[DemonWasp]

If you are pausing execution to see output, you are doing it wrong. Your output should not be disappearing: either pipe it to a file, or pipe it to a persistent console. Anything else is wrong.

This isn't something that's difficult in any real IDE, either: most will automatically redirect program output to stdout / stderr (and input, from stdin) to (or from) a console window somewhere. That console window generally doesn't go away when your program finishes its run -- and if it does, it can probably be configured to not do that. If it can't be, then it's the fault of the IDE.

[bbi5291]

The problem lies not in the fact that you yourself might want to use system("PAUSE") when debugging code for your eyes only --- really, it's up to you. The problem lies in the fact that new programmers are often being encouraged to use it, despite all its faults and the fact that getchar() (or cin.get()) is strictly better. You may have an understanding of situations in which it is appropriate or inappropriate to use system("PAUSE"), but others may not even realize that it's platform-dependent, that it has security issues, and so on.