Man Linux: Main Page and Category List

NAME

       posix_spawn, posix_spawnp - spawn a process (ADVANCED REALTIME)

SYNOPSIS

       #include <spawn.h>

       int posix_spawn(pid_t *restrict pid, const char *restrict path,
              const posix_spawn_file_actions_t *file_actions,
              const posix_spawnattr_t *restrict attrp,
              char *const argv[restrict], char *const envp[restrict]);
       int posix_spawnp(pid_t *restrict pid, const char *restrict file,
              const posix_spawn_file_actions_t *file_actions,
              const posix_spawnattr_t *restrict attrp,
              char *const argv[restrict], char * const envp[restrict]);

DESCRIPTION

       The  posix_spawn()  and  posix_spawnp()  functions  shall  create a new
       process (child process) from  the  specified  process  image.  The  new
       process  image  shall  be  constructed  from  a regular executable file
       called the new process image file.

       When a C program is executed as the result of this call,  it  shall  be
       entered as a C-language function call as follows:

              int main(int argc, char *argv[]);

       where  argc  is  the  argument  count and argv is an array of character
       pointers to  the  arguments  themselves.  In  addition,  the  following
       variable:

              extern char **environ;

       shall  be initialized as a pointer to an array of character pointers to
       the environment strings.

       The argument argv is an array of character pointers to  null-terminated
       strings.  The  last member of this array shall be a null pointer and is
       not counted  in  argc.  These  strings  constitute  the  argument  list
       available  to  the new process image. The value in argv[0] should point
       to a filename that is associated with the process image  being  started
       by the posix_spawn() or posix_spawnp() function.

       The  argument envp is an array of character pointers to null-terminated
       strings. These strings constitute the environment for the  new  process
       image. The environment array is terminated by a null pointer.

       The  number of bytes available for the child process’ combined argument
       and environment lists is {ARG_MAX}. The implementation shall specify in
       the   system   documentation   (see  the  Base  Definitions  volume  of
       IEEE Std 1003.1-2001,  Chapter  2,  Conformance)   whether   any   list
       overhead,   such  as  length  words,  null  terminators,  pointers,  or
       alignment bytes, is included in this total.

       The path argument to posix_spawn() is a pathname  that  identifies  the
       new process image file to execute.

       The  file  parameter  to  posix_spawnp()  shall  be used to construct a
       pathname that identifies the  new  process  image  file.  If  the  file
       parameter  contains a slash character, the file parameter shall be used
       as the pathname for the new process image  file.  Otherwise,  the  path
       prefix  for  this file shall be obtained by a search of the directories
       passed as the environment  variable  PATH  (see  the  Base  Definitions
       volume  of  IEEE Std 1003.1-2001, Chapter 8, Environment Variables). If
       this environment variable is not defined, the results of the search are
       implementation-defined.

       If  file_actions  is  a null pointer, then file descriptors open in the
       calling process shall remain open in  the  child  process,  except  for
       those  whose  close-on- exec flag FD_CLOEXEC is set (see fcntl() ). For
       those  file  descriptors  that  remain  open,  all  attributes  of  the
       corresponding open file descriptions, including file locks (see fcntl()
       ), shall remain unchanged.

       If file_actions is not NULL, then the  file  descriptors  open  in  the
       child process shall be those open in the calling process as modified by
       the spawn file actions  object  pointed  to  by  file_actions  and  the
       FD_CLOEXEC  flag of each remaining open file descriptor after the spawn
       file actions have been processed.  The effective  order  of  processing
       the spawn file actions shall be:

        1. The  set  of  open  file  descriptors  for  the child process shall
           initially be the same set as is open for the calling  process.  All
           attributes  of  the corresponding open file descriptions, including
           file locks (see fcntl() ), shall remain unchanged.

        2. The signal mask, signal default actions, and the effective user and
           group  IDs  for  the child process shall be changed as specified in
           the attributes object referenced by attrp.

        3. The file actions specified by the spawn file actions  object  shall
           be  performed  in  the  order in which they were added to the spawn
           file actions object.

        4. Any file descriptor that has its FD_CLOEXEC flag set (see fcntl() )
           shall be closed.

       The  posix_spawnattr_t  spawn  attributes  object  type  is  defined in
       <spawn.h>. It shall contain at least the attributes defined below.

       If the POSIX_SPAWN_SETPGROUP flag is set in the  spawn-flags  attribute
       of  the  object  referenced by attrp, and the spawn-pgroup attribute of
       the same object is non-zero, then the child’s process group shall be as
       specified  in  the  spawn-pgroup  attribute of the object referenced by
       attrp.

       As a special case, if the POSIX_SPAWN_SETPGROUP  flag  is  set  in  the
       spawn-flags attribute of the object referenced by attrp, and the spawn-
       pgroup attribute of the same object is set  to  zero,  then  the  child
       shall  be  in  a new process group with a process group ID equal to its
       process ID.

       If the  POSIX_SPAWN_SETPGROUP  flag  is  not  set  in  the  spawn-flags
       attribute  of  the  object  referenced  by attrp, the new child process
       shall inherit the parent’s process group.

       If  the  POSIX_SPAWN_SETSCHEDPARAM  flag  is  set  in  the  spawn-flags
       attribute     of     the    object    referenced    by    attrp,    but
       POSIX_SPAWN_SETSCHEDULER is  not  set,  the  new  process  image  shall
       initially  have  the  scheduling policy of the calling process with the
       scheduling parameters specified in the  spawn-schedparam  attribute  of
       the object referenced by attrp.

       If   the  POSIX_SPAWN_SETSCHEDULER  flag  is  set  in  the  spawn-flags
       attribute of the object referenced by attrp (regardless of the  setting
       of  the  POSIX_SPAWN_SETSCHEDPARAM  flag),  the new process image shall
       initially have the scheduling policy specified in the spawn-schedpolicy
       attribute  of  the  object  referenced  by  attrp  and  the  scheduling
       parameters specified in the  spawn-schedparam  attribute  of  the  same
       object.

       The  POSIX_SPAWN_RESETIDS  flag  in  the  spawn-flags  attribute of the
       object referenced by attrp governs the effective user ID of  the  child
       process.  If  this flag is not set, the child process shall inherit the
       parent process’ effective user ID. If  this  flag  is  set,  the  child
       process’ effective user ID shall be reset to the parent’s real user ID.
       In either case, if the set-user-ID mode bit of the  new  process  image
       file  is  set,  the effective user ID of the child process shall become
       that file’s owner ID before the new process image begins execution.

       The POSIX_SPAWN_RESETIDS flag  in  the  spawn-flags  attribute  of  the
       object  referenced  by attrp also governs the effective group ID of the
       child process. If this flag is not set, the child process shall inherit
       the  parent process’ effective group ID. If this flag is set, the child
       process’ effective group ID shall be reset to the parent’s  real  group
       ID.  In  either  case,  if the set-group-ID mode bit of the new process
       image file is set, the effective group ID of the  child  process  shall
       become  that  file’s  group  ID  before  the  new  process image begins
       execution.

       If the POSIX_SPAWN_SETSIGMASK flag is set in the spawn-flags  attribute
       of  the  object  referenced by attrp, the child process shall initially
       have the signal mask specified in the spawn-sigmask  attribute  of  the
       object referenced by attrp.

       If  the  POSIX_SPAWN_SETSIGDEF flag is set in the spawn-flags attribute
       of the object referenced by attrp, the signals specified in the  spawn-
       sigdefault  attribute  of the same object shall be set to their default
       actions in the child process. Signals set to the default action in  the
       parent process shall be set to the default action in the child process.

       Signals set to be caught by the calling process shall  be  set  to  the
       default action in the child process.

       Except  for  SIGCHLD,  signals set to be ignored by the calling process
       image shall be set to be ignored by the child process, unless otherwise
       specified  by  the  POSIX_SPAWN_SETSIGDEF  flag being set in the spawn-
       flags attribute of the object referenced by attrp and the signals being
       indicated in the spawn-sigdefault attribute of the object referenced by
       attrp.

       If the SIGCHLD signal is set to be ignored by the calling  process,  it
       is  unspecified  whether  the SIGCHLD signal is set to be ignored or to
       the default action in the child process, unless otherwise specified  by
       the  POSIX_SPAWN_SETSIGDEF  flag being set in the spawn_flags attribute
       of the  object  referenced  by  attrp  and  the  SIGCHLD  signal  being
       indicated in the spawn_sigdefault attribute of the object referenced by
       attrp.

       If the value of the attrp pointer is NULL, then the default values  are
       used.

       All  process  attributes, other than those influenced by the attributes
       set in the object referenced by attrp as specified above or by the file
       descriptor manipulations specified in file_actions, shall appear in the
       new process image as though fork() had been called to  create  a  child
       process  and  then  a  member  of the exec family of functions had been
       called by the child process to execute the new process image.

       It is implementation-defined whether the fork  handlers  are  run  when
       posix_spawn() or posix_spawnp() is called.

RETURN VALUE

       Upon  successful  completion,  posix_spawn()  and  posix_spawnp() shall
       return the process ID of the child process to the  parent  process,  in
       the  variable  pointed  to by a non-NULL pid argument, and shall return
       zero as the function return value. Otherwise, no child process shall be
       created,  the  value  stored into the variable pointed to by a non-NULL
       pid is unspecified, and an  error  number  shall  be  returned  as  the
       function  return  value to indicate the error. If the pid argument is a
       null pointer, the process ID of  the  child  is  not  returned  to  the
       caller.

ERRORS

       The posix_spawn() and posix_spawnp() functions may fail if:

       EINVAL The value specified by file_actions or attrp is invalid.

       If  this  error  occurs  after the calling process successfully returns
       from the posix_spawn() or posix_spawnp() function,  the  child  process
       may exit with exit status 127.

       If  posix_spawn()  or  posix_spawnp()  fail for any of the reasons that
       would cause fork() or one of the exec family of functions to  fail,  an
       error  value  shall  be  returned  as  described  by  fork()  and exec,
       respectively (or,  if  the  error  occurs  after  the  calling  process
       successfully  returns,  the  child  process shall exit with exit status
       127).

       If POSIX_SPAWN_SETPGROUP is set in the  spawn-flags  attribute  of  the
       object  referenced  by attrp, and posix_spawn() or posix_spawnp() fails
       while changing the child’s process  group,  an  error  value  shall  be
       returned  as  described by setpgid() (or, if the error occurs after the
       calling process successfully returns, the child process shall exit with
       exit status 127).

       If POSIX_SPAWN_SETSCHEDPARAM is set and POSIX_SPAWN_SETSCHEDULER is not
       set in the spawn-flags attribute of the  object  referenced  by  attrp,
       then  if  posix_spawn()  or posix_spawnp() fails for any of the reasons
       that would cause sched_setparam() to fail,  an  error  value  shall  be
       returned  as  described  by  sched_setparam()  (or, if the error occurs
       after the calling process successfully returns, the child process shall
       exit with exit status 127).

       If  POSIX_SPAWN_SETSCHEDULER is set in the spawn-flags attribute of the
       object referenced by attrp,  and  if  posix_spawn()  or  posix_spawnp()
       fails  for  any of the reasons that would cause sched_setscheduler() to
       fail,  an   error   value   shall   be   returned   as   described   by
       sched_setscheduler() (or, if the error occurs after the calling process
       successfully returns, the child process shall  exit  with  exit  status
       127).

       If  the  file_actions  argument  is  not NULL, and specifies any close,
       dup2, or  open  actions  to  be  performed,  and  if  posix_spawn()  or
       posix_spawnp()  fails  for any of the reasons that would cause close(),
       dup2(), or open()  to  fail,  an  error  value  shall  be  returned  as
       described  by  close(),  dup2(),  and  open(), respectively (or, if the
       error occurs after the calling process successfully returns, the  child
       process  shall  exit with exit status 127). An open file action may, by
       itself, result in any of the errors described by close() or dup2(),  in
       addition to those described by open().

       The following sections are informative.

EXAMPLES

       None.

APPLICATION USAGE

       These  functions  are part of the Spawn option and need not be provided
       on all implementations.

RATIONALE

       The posix_spawn() function and its close relation  posix_spawnp()  have
       been  introduced  to overcome the following perceived difficulties with
       fork(): the fork() function is difficult  or  impossible  to  implement
       without swapping or dynamic address translation.

        * Swapping is generally too slow for a realtime environment.

        * Dynamic  address  translation is not available everywhere that POSIX
          might be useful.

        * Processes are too useful to simply option out of POSIX  whenever  it
          must run without address translation or other MMU services.

       Thus,  POSIX  needs process creation and file execution primitives that
       can be efficiently implemented without address translation or other MMU
       services.

       The  posix_spawn()  function is implementable as a library routine, but
       both  posix_spawn()  and  posix_spawnp()   are   designed   as   kernel
       operations.  Also,  although  they  may be an efficient replacement for
       many fork()/ exec pairs,  their  goal  is  to  provide  useful  process
       creation  primitives  for systems that have difficulty with fork(), not
       to provide drop-in replacements for fork()/ exec.

       This view of the role of posix_spawn()  and  posix_spawnp()  influenced
       the  design  of  their  API.  It  does  not attempt to provide the full
       functionality  of  fork()/  exec  in  which  arbitrary   user-specified
       operations  of any sort are permitted between the creation of the child
       process and the execution of the new  process  image;  any  attempt  to
       reach  that  level  would  need  to  provide  a programming language as
       parameters.  Instead,  posix_spawn()  and  posix_spawnp()  are  process
       creation primitives like the Start_Process and Start_Process_Search Ada
       language bindings package POSIX_Process_Primitives and also like  those
       in  many  operating  systems  that  are not UNIX systems, but with some
       POSIX-specific additions.

       To achieve its coverage goals, posix_spawn()  and  posix_spawnp()  have
       control  of  six  types of inheritance: file descriptors, process group
       ID, user and group ID, signal mask, scheduling, and whether each signal
       ignored  in the parent will remain ignored in the child, or be reset to
       its default action in the child.

       Control of file descriptors  is  required  to  allow  an  independently
       written  child  process image to access data streams opened by and even
       generated or read by the  parent  process  without  being  specifically
       coded  to  know which parent files and file descriptors are to be used.
       Control of the process group ID is required to control  how  the  child
       process’ job control relates to that of the parent.

       Control  of  the  signal  mask  and  signal defaulting is sufficient to
       support the implementation of system(). Although support  for  system()
       is   not   explicitly   one   of   the   goals  for  posix_spawn()  and
       posix_spawnp(), it is covered under the "at least 50%" coverage goal.

       The intention is that the normal  file  descriptor  inheritance  across
       fork(),  the subsequent effect of the specified spawn file actions, and
       the normal file descriptor inheritance across one of the exec family of
       functions   should   fully   specify   open   file   inheritance.   The
       implementation need make no decisions regarding the set  of  open  file
       descriptors  when  the  child  process  image  begins  execution, those
       decisions having already been made by the caller and expressed  as  the
       set  of open file descriptors and their FD_CLOEXEC flags at the time of
       the call and the spawn file actions object specified in  the  call.  We
       have  been  assured  that  in  cases  where the POSIX Start_Process Ada
       primitives  have  been  implemented  in  a  library,  this  method   of
       controlling file descriptor inheritance may be implemented very easily.

       We can identify several problems with posix_spawn() and posix_spawnp(),
       but  there  does  not  appear  to  be  a solution that introduces fewer
       problems. Environment modification for  child  process  attributes  not
       specifiable via the attrp or file_actions arguments must be done in the
       parent process, and since  the  parent  generally  wants  to  save  its
       context,  it  is  more  costly  than similar functionality with fork()/
       exec.  It is also complicated to modify the  environment  of  a  multi-
       threaded  process  temporarily, since all threads must agree when it is
       safe for the environment to be changed.  However,  this  cost  is  only
       borne by those invocations of posix_spawn() and posix_spawnp() that use
       the additional functionality. Since extensive modifications are not the
       usual  case,  and  are  particularly  unlikely  in  time-critical code,
       keeping much of  the  environment  control  out  of  posix_spawn()  and
       posix_spawnp() is appropriate design.

       The  posix_spawn()  and  posix_spawnp()  functions  do not have all the
       power of fork()/ exec. This is to be expected.  The fork() function  is
       a  wonderfully  powerful  operation.  We do not expect to duplicate its
       functionality in a simple,  fast  function  with  no  special  hardware
       requirements.  It is worth noting that posix_spawn() and posix_spawnp()
       are very similar to the process creation operations on  many  operating
       systems that are not UNIX systems.

   Requirements
       The requirements for posix_spawn() and posix_spawnp() are:

        * They must be implementable without an MMU or unusual hardware.

        * They must be compatible with existing POSIX standards.

       Additional goals are:

        * They should be efficiently implementable.

        * They should be able to replace at least 50% of typical executions of
          fork().

        * A system with posix_spawn() and posix_spawnp()  and  without  fork()
          should be useful, at least for realtime applications.

        * A system with fork() and the exec family should be able to implement
          posix_spawn() and posix_spawnp() as library routines.

   Two-Syntax
       POSIX exec has several calling sequences with  approximately  the  same
       functionality.   These  appear  to  be  required for compatibility with
       existing practice.  Since the existing practice for the  posix_spawn*()
       functions  is  otherwise  substantially  unlike  POSIX,  we  feel  that
       simplicity outweighs compatibility.  There  are,  therefore,  only  two
       names for the posix_spawn*() functions.

       The   parameter   list   does  not  differ  between  posix_spawn()  and
       posix_spawnp(); posix_spawnp() interprets  the  second  parameter  more
       elaborately than posix_spawn().

   Compatibility with POSIX.5 (Ada)
       The   Start_Process   and   Start_Process_Search  procedures  from  the
       POSIX_Process_Primitives package  from  the  Ada  language  binding  to
       POSIX.1  encapsulate  fork() and exec functionality in a manner similar
       to that of posix_spawn() and posix_spawnp().   Originally,  in  keeping
       with  our  simplicity  goal,  the  standard  developers had limited the
       capabilities of posix_spawn() and posix_spawnp() to  a  subset  of  the
       capabilities  of  Start_Process  and Start_Process_Search; certain non-
       default capabilities were not supported. However, based on  suggestions
       by  the ballot group to improve file descriptor mapping or drop it, and
       on the advice of an Ada Language Bindings  working  group  member,  the
       standard  developers  decided  that  posix_spawn()  and  posix_spawnp()
       should  be  sufficiently  powerful  to  implement   Start_Process   and
       Start_Process_Search. The rationale is that if the Ada language binding
       to such a primitive had already been  approved  as  an  IEEE  standard,
       there  can  be little justification for not approving the functionally-
       equivalent parts of a C binding. The only three  capabilities  provided
       by   posix_spawn()   and   posix_spawnp()  that  are  not  provided  by
       Start_Process and Start_Process_Search are  optionally  specifying  the
       child’s  process  group  ID,  the set of signals to be reset to default
       signal handling in the child process, and the child’s scheduling policy
       and parameters.

       For  the  Ada language binding for Start_Process to be implemented with
       posix_spawn(), that binding would need  to  explicitly  pass  an  empty
       signal  mask and the parent’s environment to posix_spawn() whenever the
       caller of Start_Process  allowed  these  arguments  to  default,  since
       posix_spawn()   does   not   provide  such  defaults.  The  ability  of
       Start_Process to mask user-specified signals during  its  execution  is
       functionally  unique to the Ada language binding and must be dealt with
       in the binding separately from the call to posix_spawn().

   Process Group
       The process group inheritance field can  be  used  to  join  the  child
       process with an existing process group. By assigning a value of zero to
       the spawn-pgroup attribute of  the  object  referenced  by  attrp,  the
       setpgid()  mechanism  will  place  the  child  process in a new process
       group.

   Threads
       Without the posix_spawn() and posix_spawnp() functions, systems without
       address  translation  can  still  use threads to give an abstraction of
       concurrency. In many cases, thread creation suffices,  but  it  is  not
       always   a   good  substitute.  The  posix_spawn()  and  posix_spawnp()
       functions are considerably "heavier" than  thread  creation.  Processes
       have  several  important  attributes  that threads do not. Even without
       address  translation,  a  process  may   have   base-and-bound   memory
       protection.   Each process has a process environment including security
       attributes and file capabilities, and powerful  scheduling  attributes.
       Processes  abstract  the  behavior  of  non-uniform-memory-architecture
       multi-processors better than threads, and they are more  convenient  to
       use for activities that are not closely linked.

       The  posix_spawn()  and  posix_spawnp() functions may not bring support
       for multiple processes to every configuration. Process creation is  not
       the only piece of operating system support required to support multiple
       processes. The total cost of support  for  multiple  processes  may  be
       quite high in some circumstances.  Existing practice shows that support
       for multiple processes is uncommon and threads are common  among  "tiny
       kernels".   There  should,  therefore, probably continue to be AEPs for
       operating systems with only one process.

   Asynchronous Error Notification
       A library implementation of posix_spawn() or posix_spawnp() may not  be
       able  to  detect all possible errors before it forks the child process.
       IEEE Std 1003.1-2001 provides for an error indication returned  from  a
       child process which could not successfully complete the spawn operation
       via a special exit status which may be detected using the status  value
       returned by wait() and waitpid().

       The stat_val interface and the macros used to interpret it are not well
       suited to the purpose of returning API errors, but they  are  the  only
       path  available  to  a library implementation.  Thus, an implementation
       may cause the child process to exit with exit status 127 for any  error
       detected   during   the   spawn  process  after  the  posix_spawn()  or
       posix_spawnp() function has successfully returned.

       The standard developers had proposed using  two  additional  macros  to
       interpret  stat_val.  The  first,  WIFSPAWNFAIL,  would have detected a
       status that indicated  that  the  child  exited  because  of  an  error
       detected  during  the posix_spawn() or posix_spawnp() operations rather
       than during actual execution of the child process  image;  the  second,
       WSPAWNERRNO,  would  have  extracted  the  error  value if WIFSPAWNFAIL
       indicated a failure.  Unfortunately, the ballot group strongly  opposed
       this because it would make a library implementation of posix_spawn() or
       posix_spawnp() dependent on kernel modifications  to  waitpid()  to  be
       able  to  embed  special  information  in  stat_val to indicate a spawn
       failure.

       The 8 bits  of  child  process  exit  status  that  are  guaranteed  by
       IEEE Std 1003.1-2001 to be accessible to the waiting parent process are
       insufficient to disambiguate a spawn error from any other kind of error
       that  may  be  returned by an arbitrary process image. No other bits of
       the exit status are required to be visible in stat_val, so these macros
       could  not  be  strictly implemented at the library level. Reserving an
       exit status of 127 for such spawn errors is consistent with the use  of
       this  value  by  system()  and  popen()  to  signal  failures  in these
       operations that occur after the function  has  returned  but  before  a
       shell  is  able  to  execute.  The exit status of 127 does not uniquely
       identify this  class  of  error,  nor  does  it  provide  any  detailed
       information   on  the  nature  of  the  failure.  Note  that  a  kernel
       implementation of posix_spawn() or  posix_spawnp()  is  permitted  (and
       encouraged)  to  return  any possible error as the function value, thus
       providing more detailed failure information to the parent process.

       Thus,  no  special  macros  are  available  to   isolate   asynchronous
       posix_spawn() or posix_spawnp() errors. Instead, errors detected by the
       posix_spawn() or posix_spawnp() operations in the context of the  child
       process  before  the new process image executes are reported by setting
       the child’s exit status  to  127.  The  calling  process  may  use  the
       WIFEXITED  and  WEXITSTATUS macros on the stat_val stored by the wait()
       or waitpid() functions to detect spawn  failures  to  the  extent  that
       other status values with which the child process image may exit (before
       the parent can conclusively determine that the child process image  has
       begun execution) are distinct from exit status 127.

FUTURE DIRECTIONS

       None.

SEE ALSO

       alarm()  ,  chmod()  ,  close()  ,  dup() , exec() , exit() , fcntl() ,
       fork()  ,  kill()  ,  open()  ,  posix_spawn_file_actions_addclose()  ,
       posix_spawn_file_actions_adddup2() , posix_spawn_file_actions_addopen()
       , posix_spawn_file_actions_destroy() ,  ,  posix_spawnattr_destroy()  ,
       posix_spawnattr_init()      ,     posix_spawnattr_getsigdefault()     ,
       posix_spawnattr_getflags()     ,     posix_spawnattr_getpgroup()      ,
       posix_spawnattr_getschedparam()  ,  posix_spawnattr_getschedpolicy()  ,
       posix_spawnattr_getsigmask()   ,   posix_spawnattr_setsigdefault()    ,
       posix_spawnattr_setflags()      ,     posix_spawnattr_setpgroup()     ,
       posix_spawnattr_setschedparam()  ,  posix_spawnattr_setschedpolicy()  ,
       posix_spawnattr_setsigmask()  , sched_setparam() , sched_setscheduler()
       , setpgid() ,  setuid()  ,  stat()  ,  times()  ,  wait()  ,  the  Base
       Definitions volume of IEEE Std 1003.1-2001, <spawn.h>

COPYRIGHT

       Portions  of  this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
       --  Portable  Operating  System  Interface (POSIX), The Open Group Base
       Specifications Issue 6, Copyright (C) 2001-2003  by  the  Institute  of
       Electrical  and  Electronics  Engineers, Inc and The Open Group. In the
       event of any discrepancy between this version and the original IEEE and
       The  Open Group Standard, the original IEEE and The Open Group Standard
       is the referee document. The original Standard can be  obtained  online
       at http://www.opengroup.org/unix/online.html .