Hide sh: -c error messages when calling “system” in c++ Linux - c++

Question

I'm using system to execute a command with it's arguments. I don't want to use exec/fork.
When I have unmatched quotes in my command this error appears:
sh: -c: line 0: unexpected EOF while looking for matching `''
sh: -c: line 1: syntax error: unexpected end of file
How do I suppress these shell's error messages? I tried adding >/dev/null 2>&1 at the end of the invalid command but it doesn't suppress the shell error message. For background, I'm running user supplied commands which may or may not be valid. I can't know in advance if they'll be valid or not, but I want to suppress the error messages regardless.
Here's an example of code that generates the type of error I'm trying to suppress:
int main()
{
// This command is meant to be invalid as I'm trying to suppress the shell syntax error message
system("date ' >/dev/null 2>&1");
return 0;
}
Can you help me?

Answer 1

Think that system forks a process and then executes the command you've provided. The new process inherits the descriptor from its parent and that new process is writing in its standard error.
So, this code snippet may do what you want:
#include <stdlib.h>
#include <unistd.h>
int main()
{
int duperr;
duperr = dup(2);
close(2); /* close stderr so the new process can't output the error */
system("date '");
dup2(duperr, 2);
close(duperr);
/* here you can use stderr again */
write(2, "hello world\n", 12);
return 0;
}
To make writes to stderr be silently suppressed, you can output the errors to /dev/null:
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <stdio.h>
int main(void) {
int devnull_fd, duperr_fd;
/* get a descriptor to /dev/null (devnull_fd) */
devnull_fd = open("/dev/null", O_WRONLY | O_APPEND);
/* save a descriptor "pointing" to the actual stderr (duperr_fd) */
duperr_fd = dup(STDERR_FILENO);
/* now STDERR_FILENO "points" to "/dev/null" */
dup2(devnull_fd, STDERR_FILENO);
system("date '");
/* restore stderr */
dup2(duperr_fd, STDERR_FILENO);
close(duperr_fd);
close(devnull_fd);
/* here you can use stderr again */
write(STDERR_FILENO, "hello world\n", 12);
return 0;
}
Remember to check the return value of the function calls.

Answer 2

The logical problem is that you're not redirecting anything because the part >/dev/null 2>&1 ends up being contained in a single-quoted part.
The string however doesn't end and therefore bash complains on stderr.
The solution for this specific case is to quote single-quotes by preceding them with a backslash, i.e. to call system("date \\' >/dev/null 2>&1"). Note however that bash exact quoting rules are a small nightmare.
A workaround I can think to in general is to save the command in a file, say cmd.txt, and then execute
system("bash < cmd.txt >/dev/null 2>&1");
May be this can be done also with bash -c without creating the file but I simply was not able to make any sense of single quote escaping rules for -c and I'm not going to waste neurons on the totally broken bash grammar.

Answer 3

You might want to run a correct command, then remove the quote, so
system("date >/dev/null 2>&1");
However, what is the point of running that? If (your PATH is common enough so that...) date is indeed /bin/date (see date(1)...) its only effect is to produce some output, and you are discarding it by redirecting it to /dev/null. So the only visible effect of your call to system is to spend several millions of CPU cycles. Of course, in weird cases, it could fail (e.g. because /bin/sh does not exist, /bin/date does not exist, fork has failed, etc...) ....
Maybe you are coding a shell. Then you should parse the command and do fork & execve .....
If you want to get the output of some command like date, better use popen(3) with pclose. In the particular case of the date it is much better to use time(2), localtime(3), strftime(3) (then you don't need to depend upon an external command, and you won't need to use popen)
If you really want to suppress the output of the shell started by system you could do the fork & execve (of bin/sh -c) yourself and redirect the standard and error outputs (to a file descriptor opening /dev/null) with dup2. See also daemon(3) & wordexp(3)
Maybe embedding an interpreter in your application (e.g. lua or guile) would be more sensible (assuming you don't care about user mistakes)