CODEWITHSUNDEEP
c++linuxgcc
thedarkside ofthemoon
thedarkside ofthemoon

Reputation: 2291

Create an executable that calls another executable?

I want to make a small application that runs another application multiple times for different input parameters.

  1. Is this already done?
  2. Is it wrong to use system("myAp param"), for each call (of course with different param value)?

I am using kdevelop on Linux-Ubuntu.

From your comments, I understand that instead of:

system("path/to/just_testing p1 p2");

I shall use:

execl("path/to/just_testing", "path/to/just_testing", "p1", "p2", (char *) 0);

Is it true? You are saying that execl is safer than system and it is better to use?

Upvotes: 1

Views: 627

Answers (2)

manlio
manlio

Reputation: 18972

DIFFERENCES BETWEEN SYSTEM AND EXEC

  • system() will invoke the default command shell, which will execute the command passed as argument.

    Your program will stop until the command is executed, then it'll continue.

    The value you get back is not about the success of the command itself, but regards the correct opening of command shell.

    A plus of system() is that it's part of the standard library.

  • With exec(), your process (the calling process) is replaced. Moreover you cannot invoke a script or an internal command. You could follow a commonly used technique: Differences between fork and exec

So they are quite different (for further details you could see: Difference between "system" and "exec" in Linux?).

A correct comparison is between POSIX spawn() and system(). spawn() is more complex but it allows to read the external command's return code.

SECURITY

system() (or popen()) can be a security risk since certain environment variables (like $IFS / $PATH) can be modified so that your program will execute external programs you never intended it to (i.e. a command is specified without a path name and the command processor path name resolution mechanism is accessible to an attacker).

Also the system() function can result in exploitable vulnerabilities:

  • when passing an unsanitized or improperly sanitized command string originating from a tainted source;
  • if a relative path to an executable is specified and control over the current working directory is accessible to an attacker;
  • if the specified executable program can be spoofed by an attacker.

For further details: ENV33-C. Do not call system()

Anyway... I like Somberdon's answer.

Upvotes: 3

Kats
Kats

Reputation: 143

In the non-professional field, using system() is perfectly acceptable, but be warned, people will always tell you that it's "wrong." It's not wrong, it's a way of solving your problem without getting too complicated. It's a bit sloppy, yes, but certainly is still a usable (if a bit less portable) option. The data returned by the system() call will be the return value of the application you're calling. Based on the limited information in your post, I assume that's all you're really wanting to know.

Upvotes: 4

Related Questions