9

I'm new to C++, and I've read and heard that using system calls is bad practice. So what if you need to use system() to run a Windows command like ipconfig or netstat. Is it still evil or is that considered an acceptable use of system()? I'm writing a program to collect a variety of information about the system and I use system() many times and pipe the output into text files for review.

Son of a Sailor
  • 915
  • 3
  • 14
  • 22
  • 2
    Ask Windows to do it - `CreateProcess()` - [How do I call ::CreateProcess in c++ to launch a Windows executable?](http://stackoverflow.com/questions/42531/how-do-i-call-createprocess-in-c-to-launch-a-windows-executable) – Alex K. Aug 05 '13 at 17:59
  • 1
    That's all possible, everything these utilities can do you can do in your own code as well. But it can be pretty important that you don't try to do it all in one massive gulp. Get version 0.1 going, you can always make it better. – Hans Passant Aug 05 '13 at 18:33
  • You also want to consider popen()/pclose() so you at least avoid the text file. Otherwise, that's a very Unix way of doing things, but there is only one good reason to avoid such practice: the parsing of the output will fail over time as the format changes... – Alexis Wilke Aug 05 '13 at 18:56
  • Why write this crap in C++? Get some Ruby, or Python, or whatever.. Save yourself some time and have a little fun. –  Aug 05 '13 at 19:41
  • Short answer: using system() is bad practice in finished production applications, unless there really is no other alternative, which is rarely the case. Using system() is fine if you're writing something for your own use, or as an exercise, or as a proof-of-concept or early version. – Harry Johnston Aug 08 '13 at 01:02

2 Answers2

8

Most of the calls you'd make have Windows API calls you can use directly. Ideally, you'd just call the appropriate Windows API call instead of launching a process, writing to a file, then parsing the file.

That being said, on Windows, CreateProcess will launch a process and provide you a lot more control than a call to system. This includes using STARTUPINFO to provide your own HANDLE for the process standard output stream, which means you can directly read from the process without writing to a file.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
2

The problem is not the use of system, but the abuse of it in wrong frequent situations.

  • Calling system means invoke the command interpreter (CMD) giving it a string to parse. If that string is a command will be executed, if it is a program will be called because the command interpreter behave that way.

  • Calling CreateProcess means just letting the kernel to boot a process that will execute a given program. There is no command interpreter invocation.

Now the point becomes "does the command interpreter have a role in your execution, or will it be just a passive slave?

In the first case (more rare) system is most likely the real way to go.

In the second case (more frequent), placing a command interpreter in between makes the real execution dependent on the eventual tweaks the system has placed around it (for example, launching a batch instead of your command) you may not be aware of when running on your user's machines. And this can even translate in potential security breaches.)

The most common use of system, is -however- the system("pause") frequently seen to keep the console open after a program termination. It can be a quick and dirty solution, but that's not in general the way to go, for two reasons:

  • If a program is executed inside another process there can be no-one waiting to press a key to return: just launch the program in an already open shell, and the shell will remain open.

  • If a program is designed to be interactive (so there is a human providing input), then usign normal i/o functionality will be more appropriate.

Emilio Garavaglia
  • 20,229
  • 2
  • 46
  • 63