Alternative to system()

Question

I recently got into c++ programming, and I have gotten a lot of experience with it. My past few programs have been using the system() command, which I have read is supposed to be a really bad idea. First of all, why is it such a bad idea? I am using it on Linux for things like clear the screen [ex: system("clear") ] and to launch other parts of my program, such as returning to a menu [ex: system("./menu") ]. Is it okay to use it for things as I showed above (which are the main things anyway), or is there a better solution? I just program as a hobby, but I still really don't like making crappy programs. Thanks in advance!!

Answer 1

The problems with system can be categorised as three or four different issues:

1. Resource usage - system uses a fair bit of system resources, both memory, execution time and filesystem I/O is needed to create a new process and execute a shell inside it.

2. Portability of external programs (system("clear"); won't work on Windows, since the "cls" command is used to clear the screen - or at least won't clear the screen, if you are really unlucky, someone wrote a cleanup program called "clear" that erases the customer database if you are a sysadmin user. It gets even more fun if you need to pass arguments to the program, and different environments use different set(s) of options and arguments.

3. Security. If you call system("clear"); from your application, and someone replaced the local "clear" with some different code that also erases some files, or something more or less evil, that would be a bad thing. Since you start an external program, you need to either be very specific to the path of that program, and then you run into portability problems.

What the solution is really depends on what you are trying to achieve.

And for a SMALL number of cases, using system or one of the closely related functions, such as popen() would be the right thing. On Linux and other flavours of Unix, using fork() followed by exec() may be the right thing - at least it reduces the resource overhead case.

In the case of system("clear");, it can can be replaced with outputting a short sequence of characters - such as "\033[0J", which works on any ANSI/VT100 compatible terminal/console window - which pretty much covers anything you'd ever find these days unless you REALLY go searching for obscure and unusual systems. [Except Windows, where you need to call the "clearscreen" function in the console API].

In general, if portability is a need, system() is usually not a good solution, and using a library that is available on multiple platforms [or creating such yourself] is a better choice.

Both from a resource and portability standpoint, your example of calling system("./menu"); doesn't sound like the right thing either, since that would start a NEW menu program, which you probably already did run one - unless your menu program exits after successful choice. If you keep starting more and more processes, it will EVENTUALLY fill the entire system, even if it takes a while on a modern system with lots of memory.

Here, my solution would be to build a larger program that contains all of the functionality, and have the main menu simply call the functions within the program. It is often possible to create multiple layer of menus using a hierarchical structure of some sort, where one menu choice either leads to another menu or "doing something" - a class hierarchy or some sort of table of function pointers MAY be the right solution here, but again, it's a pretty broad subject, and there is definitely not ONE answer that is right.