On Aug 12, 2008, at 5:18 PM, Marc Heiler wrote:

> Could you point out where it is defined? I could understand if the FHS
> wants to impose such locations, but someone claimed that POSIX in  
> itself
> makes that claim.

[ahoward@localhost ~]$ PAGER=cat man system
SYSTEM 
(3)                                                                   
Linux ProgrammerÃÔ  
Manual 
                                                                    
SYSTEM(3)



NAME
        system - execute a shell command

SYNOPSIS
        #include <stdlib.h>

        int system(const char *string);

DESCRIPTION
        system()  executes  a  command  specified  in  string  by  
calling /bin/sh -c string, and returns after the command has been  
completed.  During execution of the command,
        SIGCHLD will be blocked, and SIGINT and SIGQUIT will be ignored.

RETURN VALUE
        The value returned is -1 on error (e.g. fork failed), and the  eturn status of the command otherwise.  This latter return status is  n 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  tatus will be that of a command that does exit(127).

        If the value of string is NULL, system() returns nonzero if  
the shell is available, and zero if not.

        system() does not affect the wait status of any other children.

CONFORMING TO
        ANSI C, POSIX.2, BSD 4.3

NOTES
        As  mentioned, system() ignores SIGINT and SIGQUIT.  This may  ake programs that call it from a loop uninterruptable, 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 suid or sgid  
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  ith suid or sgid privileges on sys-
        tems on which /bin/sh is bash version 2, since bash 2 drops  
privileges on startup.  (Debian uses a modified bash which does not do  his when invoked as sh.)

        The check for the availability of /bin/sh is not actually  
performed; it is always assumed to be available.  ISO C specifies the  heck, but POSIX.2  specifies  that  the
        return shall always be non-zero, since a system without the  
shell is not conforming, and it is this that is implemented.

        It is possible for the shell command to return 127, so that  
code is not a sure indication that the execve() call failed.

SEE ALSO
        sh(1), signal(2), wait(2), exec(3)



http://en.wikipedia.org/wiki/System_(C_Standard_Library)



a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama