system — execute a shell command
#include <stdlib.h>
int
system( |
const char * | command) ; |
system
() executes a command
specified in command
by calling /bin/sh −c
command
, and returns
after the command has been completed. During execution of the
command, SIGCHLD
will be
blocked, and SIGINT
and
SIGQUIT
will be ignored.
The value returned is −1 on error (e.g. fork(2) failed), and the
return status of the command otherwise. This latter return
status is in the format specified in wait(2). Thus, the exit
code of the command will be WEXITSTATUS(status)
. In case
/bin/sh
could not be executed,
the exit status will be that of a command that does
exit(127)
.
If the value of command
is NULL, system
() returns non-zero if the shell is
available, and zero if not.
system
() does not affect the
wait status of any other children.
If the _XOPEN_SOURCE
feature
test macro is defined, then the macros described in wait(2) (WEXITSTATUS
(), etc.) are made available
when including <stdlib.h>
.
As mentioned, system
()
ignores SIGINT
and SIGQUIT
. This may make programs that call
it from a loop uninterruptible, unless they take care
themselves to check the exit status of the child. E.g.
while (something) { int ret = system("foo"); if (WIFSIGNALED(ret) && (WTERMSIG(ret) == SIGINT || WTERMSIG(ret) == SIGQUIT)) break; }
Do not use system
() from a
program with set-user-ID or set-group-ID privileges, because
strange values for some environment variables might be used
to subvert system integrity. Use the exec(3) family of functions
instead, but not execlp(3) or execvp(3). system
() will not, in fact, work properly
from programs with set-user-ID or set-group-ID privileges on
systems on which /bin/sh
is
bash version 2, since bash 2 drops privileges on startup.
(Debian uses a modified bash which does not do this when
invoked as sh
.)
In versions of glibc before 2.1.3, the check for the
availability of /bin/sh
was not
actually performed if command
was NULL; instead it
was always assumed to be available, and system
() always returned 1 in this case.
Since glibc 2.1.3, this check is performed because, even
though POSIX.1-2001 requires a conforming implementation to
provide a shell, that shell may not be available or
executable if the calling program has previously called
chroot(2) (which is not
specified by POSIX.1-2001).
It is possible for the shell command to return 127, so that code is not a sure indication that the execve(2) call failed.
sh(1), signal(2), wait(2), exec(3)
|