This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Patch implementing EXECUTE_COMMAND_LINE

Gerald Pfeifer wrote:
> On Sun, 17 May 2009, Steve Kargl wrote:
>> Are you sure that this is asynchronous?  FreeBSD's manpage
>> indicates that system(3) is synchronous. 
>> man 3 system
>>      The system() function hands the argument string to the command inter-
>>      preter sh(1).  The calling process waits for the shell to finish execut-
>>      ing the command, ignoring SIGINT and SIGQUIT, and blocking SIGCHLD.
> Same on GNU/Linux with glibc:
>        system()  executes a command specified in command by calling /bin/sh -c
>        command, and returns after the command has been completed.  During exe-
>        cution  of the command, SIGCHLD will be blocked, and SIGINT and SIGQUIT
>        will be ignored.

Which is not too surprising as POSIX (IEEE Std 1003.1-2001) has the same:

>        If  command  is  a null pointer, the system() function shall
> determine whether the host environment has a
>        command processor. If command is not a null pointer, the
> system() function shall pass the string  pointed
>        to  by  command  to that command processor to be executed in an
> implementation-defined manner; this might
>        then cause the program calling system() to behave in a
> non-conforming manner or to terminate.
>        The environment of the executed command shall be as if a child
> process were created using fork(), and the
>        child process invoked the sh utility using execl() as follows:
>               execl(<shell path>, "sh", "-c", command, (char *)0);
>        where <shell path> is an unspecified pathname for the sh utility.
>        The  system()  function  shall ignore the SIGINT and SIGQUIT
> signals, and shall block the SIGCHLD signal,
>        while waiting for the command to terminate. If this might cause
> the application to  miss  a  signal  that
>        would  have  killed it, then the application should examine the
> return value from system() and take what-
>        ever action is appropriate to the application if the command
> terminated due to receipt of a signal.
>        The system() function shall not affect the termination status
> of any child of the calling processes other
>        than the process or processes it itself creates.
>        The system() function shall not return until the child process
> has terminated.

For Windows: "system" there calls "cmd.exe", see:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]