1system(3)                  Library Functions Manual                  system(3)
2
3
4

NAME

6       system - execute a shell command
7

LIBRARY

9       Standard C library (libc, -lc)
10

SYNOPSIS

12       #include <stdlib.h>
13
14       int system(const char *command);
15

DESCRIPTION

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

RETURN VALUE

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

ERRORS

59       system() can fail with any of the same errors as fork(2).
60

ATTRIBUTES

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

STANDARDS

72       C11, POSIX.1-2008.
73

HISTORY

75       POSIX.1-2001, C89.
76

NOTES

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

BUGS

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

SEE ALSO

146       sh(1),   execve(2),  fork(2),  sigaction(2),  sigprocmask(2),  wait(2),
147       exec(3), signal(7)
148
149
150
151Linux man-pages 6.04              2023-03-30                         system(3)
Impressum