1SYSTEM(3)                  Linux Programmer's Manual                 SYSTEM(3)
2
3
4

NAME

6       system - execute a shell command
7

SYNOPSIS

9       #include <stdlib.h>
10
11       int system(const char *command);
12

DESCRIPTION

14       The  system()  library  function uses fork(2) to create a child process
15       that executes the shell command specified in command using execl(3)  as
16       follows:
17
18           execl("/bin/sh", "sh", "-c", command, (char *) NULL);
19
20       system() returns after the command has been completed.
21
22       During  execution  of  the command, SIGCHLD will be blocked, and SIGINT
23       and SIGQUIT will be  ignored,  in  the  process  that  calls  system().
24       (These  signals  will be handled according to their defaults inside the
25       child process that executes command.)
26
27       If command is NULL, then system() returns a status indicating whether a
28       shell is available on the system.
29

RETURN VALUE

31       The return value of system() is one of the following:
32
33       *  If command is NULL, then a nonzero value if a shell is available, or
34          0 if no shell is available.
35
36       *  If a child process could not be created, or its status could not  be
37          retrieved,  the  return value is -1 and errno is set to indicate the
38          error.
39
40       *  If a shell could not be executed in the child process, then the  re‐
41          turn  value  is  as  though  the  child  shell terminated by calling
42          _exit(2) with the status 127.
43
44       *  If all system calls succeed, then the return value is  the  termina‐
45          tion status of the child shell used to execute command.  (The termi‐
46          nation status of a shell is the termination status of the last  com‐
47          mand it executes.)
48
49       In  the last two cases, the return value is a "wait status" that can be
50       examined using the macros described in waitpid(2).  (i.e., WIFEXITED(),
51       WEXITSTATUS(), and so on).
52
53       system() does not affect the wait status of any other children.
54

ERRORS

56       system() can fail with any of the same errors as fork(2).
57

ATTRIBUTES

59       For  an  explanation  of  the  terms  used  in  this  section,  see at‐
60       tributes(7).
61
62       ┌────────────────────────────────────────────┬───────────────┬─────────┐
63Interface                                   Attribute     Value   
64       ├────────────────────────────────────────────┼───────────────┼─────────┤
65system()                                    │ Thread safety │ MT-Safe │
66       └────────────────────────────────────────────┴───────────────┴─────────┘
67

CONFORMING TO

69       POSIX.1-2001, POSIX.1-2008, C89, C99.
70

NOTES

72       system() provides simplicity and convenience: it handles all of the de‐
73       tails of calling fork(2), execl(3), and waitpid(2), as well as the nec‐
74       essary manipulations of signals; in addition, the  shell  performs  the
75       usual substitutions and I/O redirections for command.  The main cost of
76       system() is inefficiency: additional system calls are required to  cre‐
77       ate the process that runs the shell and to execute the shell.
78
79       If  the  _XOPEN_SOURCE  feature test macro is defined (before including
80       any header files), then the macros described in  waitpid(2)  (WEXITSTA‐
81       TUS(), etc.) are made available when including <stdlib.h>.
82
83       As  mentioned, system() ignores SIGINT and SIGQUIT.  This may make pro‐
84       grams that call it from a loop uninterruptible, unless they  take  care
85       themselves to check the exit status of the child.  For example:
86
87           while (something) {
88               int ret = system("foo");
89
90               if (WIFSIGNALED(ret) &&
91                   (WTERMSIG(ret) == SIGINT || WTERMSIG(ret) == SIGQUIT))
92                       break;
93           }
94
95       According to POSIX.1, it is unspecified whether handlers registered us‐
96       ing pthread_atfork(3) are called during the execution of system().   In
97       the glibc implementation, such handlers are not called.
98
99       In  versions  of  glibc before 2.1.3, the check for the availability of
100       /bin/sh was not actually performed if command was NULL; instead it  was
101       always  assumed to be available, and system() always returned 1 in this
102       case.  Since glibc 2.1.3, this check is performed because, even  though
103       POSIX.1-2001  requires  a conforming implementation to provide a shell,
104       that shell may not be available or executable if  the  calling  program
105       has   previously   called   chroot(2)   (which   is  not  specified  by
106       POSIX.1-2001).
107
108       It is possible for the shell command to terminate with a status of 127,
109       which yields a system() return value that is indistinguishable from the
110       case where a shell could not be executed in the child process.
111
112   Caveats
113       Do not use system() from a privileged program (a  set-user-ID  or  set-
114       group-ID  program, or a program with capabilities) because strange val‐
115       ues for some environment variables might be used to subvert system  in‐
116       tegrity.   For  example, PATH could be manipulated so that an arbitrary
117       program is executed with privilege.  Use the exec(3)  family  of  func‐
118       tions  instead, but not execlp(3) or execvp(3) (which also use the PATH
119       environment variable to search for an executable).
120
121       system() will not, in fact, work properly from programs with  set-user-
122       ID  or set-group-ID privileges on systems on which /bin/sh is bash ver‐
123       sion 2: as a security measure, bash  2  drops  privileges  on  startup.
124       (Debian  uses  a  different shell, dash(1), which does not do this when
125       invoked as sh.)
126
127       Any user input that is employed as part of command should be  carefully
128       sanitized,  to ensure that unexpected shell commands or command options
129       are not executed.  Such risks are especially grave when using  system()
130       from a privileged program.
131

BUGS

133       If  the command name starts with a hyphen, sh(1) interprets the command
134       name as an option, and the behavior is undefined.  (See the  -c  option
135       to  sh(1).)   To  work  around this problem, prepend the command with a
136       space as in the following call:
137
138               system(" -unfortunate-command-name");
139

SEE ALSO

141       sh(1),  execve(2),  fork(2),  sigaction(2),  sigprocmask(2),   wait(2),
142       exec(3), signal(7)
143

COLOPHON

145       This  page  is  part of release 5.12 of the Linux man-pages project.  A
146       description of the project, information about reporting bugs,  and  the
147       latest     version     of     this    page,    can    be    found    at
148       https://www.kernel.org/doc/man-pages/.
149
150
151
152                                  2021-03-22                         SYSTEM(3)
Impressum