execl man page on IRIX

Man page or keyword search:  
man Server   31559 pages
apropos Keyword Search (all sections)
Output format
IRIX logo
[printable version]



exec(2)								       exec(2)

NAME
     exec: execl, execv, execle, execve, execlp, execvp - execute a file

SYNOPSIS
     #include <unistd.h>

     int execl (const char *path, const char *arg0, ..., const char *argn,
	  (char *)0);

     int execv (const char *path, char *const *argv);

     int execle (const char *path, const char *arg0, ..., const char *argn,
	  (char *)0, const char *envp[]);

     int execve (const char *path, char *const *argv, char *const *envp);

     int execlp (const char *file, const char *arg0, ..., const char *argn,
	  (char *)0);

     int execvp (const char *file, char *const *argv);

DESCRIPTION
     exec in all its forms overlays a new process image on an old process.
     The new process image is constructed from an ordinary, executable file.
     This file is either an executable object file, or a file of data for an
     interpreter.  There can be no return from a successful exec because the
     calling process image is overlaid by the new process image.

     An interpreter file begins with a line of the form

	  #! pathname [arg]

     where pathname is the path of the interpreter, and arg is an optional
     argument.	This line may be up to 256 characters long.  arg includes all
     characters from the first non-space character after pathname up to, but
     not including, the newline.  Any tabs in arg are converted to spaces.
     When an interpreter file is exec'd, the system execs the specified
     interpreter.  The pathname specified in the interpreter file is passed as
     arg0 to the interpreter.  If arg was specified in the interpreter file,
     it is passed as arg1 to the interpreter.  The remaining arguments to the
     interpreter are arg0 through argn of the originally exec'd file.

     When a C program is executed, it is called as follows:

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

     where argc is the argument count, argv is an array of character pointers
     to the arguments themselves, and envp is an array of character pointers
     to the environment strings.  As indicated, argc is at least one, and the
     first member of the array points to a string containing the name of the
     file.

									Page 1

exec(2)								       exec(2)

     path points to a path name that identifies the new process file.

     file, which is only used with execlp and execvp, points to the new
     process file.  If file does not contain a slash character, the path
     prefix for this file is obtained by a search of the directories passed in
     the PATH environment variable [see environ(5)].  The environment is
     supplied typically by the shell [see sh(1)].

     If the new process file is not an executable object file, execlp and
     execvp use the contents of that file as standard input to sh(1).
     However, if the new process file is setuid or setgid, the input is passed
     via /dev/fd/N (see below for details).

     The arguments arg0, ..., argn point to null-terminated character strings.
     These strings constitute the argument list available to the new process
     image.  Minimally, arg0 must be present.  It will become the name of the
     process, as displayed by the ps command.  Conventionally, arg0 points to
     a string that is the same as path (or the last component of path).	 The
     list of argument strings is terminated by a (char *)0 argument.

     argv is an array of character pointers to null-terminated strings.	 These
     strings constitute the argument list available to the new process image.
     By convention, argv must have at least one member, and it should point to
     a string that is the same as path (or its last component).	 argv is
     terminated by a null pointer.

     envp is an array of character pointers to null-terminated strings.	 These
     strings constitute the environment for the new process image.  envp is
     terminated by a null pointer.  For execl, execv, execvp, and execlp, the
     C run-time start-off routine places a pointer to the environment of the
     calling process in the global object extern char **_environ, and it is
     used to pass the environment of the calling process to the new process.
     Unless compilation is done in a pure ANSI environment (see cc(1)), the
     global variable _environ is aliased to the well-known (but non-ANSI-
     compliant) name environ.

     File descriptors open in the calling process remain open in the new
     process, except for those whose close-on-exec flag is set; [see
     fcntl(2)].	 For those file descriptors that remain open, the file pointer
     is unchanged.  Under certain circumstances, the file descriptors
     associated with stdio may be automatically opened by libc.	 See stdio(3s)
     for more information.

     Signals that are being caught by the calling process are set to the
     default disposition in the new process image [see signal(2)].  Otherwise,
     the new process image inherits the signal dispositions of the calling
     process.

     For signals set by sigset(2), sigaction(2), or sigvec(3B), exec will
     ensure that the new process has the same system signal action for each
     signal type whose action is SIG_DFL, SIG_IGN, or SIG_HOLD as the calling
     process.  However, if the action is to catch the signal, then the action

									Page 2

exec(2)								       exec(2)

     will be reset to SIG_DFL.	All signal masks associated with handlers are
     cleared.

     If the file resides on a file system which has been mounted with the
     nosuid option [see fstab(4)] then the effective user ID, the effective
     group ID and the current capability set [see capabilities(4)] will remain
     unchanged.	 Otherwise, if the set-user-ID (SUID) mode bit of the new
     process file is set [see chmod(2)], exec sets the effective user ID of
     the new process to the owner ID of the new process file.  Similarly, if
     the set-group-ID (SGID) mode bit of the new process file is set, the
     effective group ID of the new process is set to the group ID of the new
     process file.  And finally, if attributes for the file are accessible
     [see attr_get(2)] and the SGI_CAP_FILE attribute is attached to the file
     (SCAP), then this is used to change the process' capabilities (see
     capabilities(4)).

     The real user ID, real group ID, and supplementary group IDs of the new
     process remain the same as those of the calling process.

     The saved user and group IDs of the new process are set to the effective
     user and group IDs of the calling process.

     If the effective user-ID is 0, the set-user-ID (SUID) and set-group-ID
     (SGID) file mode bits and any capabilities attached to the file (SCAP)
     will be honored when the process is being controlled by ptrace.

     When an image with set-user-ID (SUID), set-group-ID (SGID) or attached
     capabilities (SCAP) is executed it is dangerous from a security
     standpoint to respect certain environment variables which may allow
     arbitrary code to be linked into the new process image.  Examples include
     rld's _RLD*_LIST and LD_LIBRARY*_PATH environment variables and the Image
     Format Library's IFL_DATABASE environment variable (see rld(1) and
     ifl(1)), and catopen's NLSPATH environment variable, which allows user
     control of message formatting (see catopen(3C)).  As a result, these
     environment variables are ignored when such an image is executed.	The
     semantics for determining when it is dangerous to respect such
     environment variables are: the real and effective user IDs are different,
     or the real and effective group IDs are different or if a process has any
     effective or permitted capabilities.

     Allowing such environment variables to be used in these circumstances is
     dangerous because an unprivileged user may execute an image which has
     privileges associated with it.  Allowing the user to specify arbitrary
     code to be linked into the new privileged process image would give the
     user the ability to circumvent the security policies instituted by the
     system administrator.  For instance, if an arbitrary dynamic linked
     object (DSO) were linked in which provided a resolution for the symbol
     strcpy, the priviledge process could call the strcpy() function thinking
     that it was making a ``safe'' call to a standard library routine.

									Page 3

exec(2)								       exec(2)

     Because of the above security restrictions, a dynamic executable with
     attached permissions (SUID, SGID, and/or SCAP) will not be able to use
     the LD_LIBRARY*_PATH environment variables to find dynamic shared objects
     (DSO's) in non-standard library locations.	 Instead, the executable must
     either explicitly specify the locations of the DSO's it wants to load in
     its dlopen(3) calls or must have an rpath embedded within it which
     specifies the non-standard library locations that need to be searched for
     its DSO's (see the documentation for the -rpath option in ld(1)).

     Set-user-ID (SUID), set-group-ID (SGID) interpreter files and those with
     attached capabilities (SCAP) are handled in a special manner.  If
     execution of an interpreter file will change either the user orgroup ID
     or the file has attached capabilities, IRIX will open the interpreter
     file for reading (subject to the read permissions of the interpreter file
     and the user and group ID of the new process).  A pathname corresponding
     to the interpreter file descriptor will be substituted for the pathname
     of the interpreter file in the argument list passed to the intepreter.
     This pathname will be of the form /dev/fd/N where N is the number of the
     interpreter file descriptor.

     The shared memory segments attached to the calling process will not be
     attached to the new process [see shmop(2)].

     If the process is a member of a share group, it is removed from that
     share group [see sproc(2)].

     Profiling is disabled for the new process; see profil(2).

     Ability to access graphics is disabled.

     The new process also inherits the following attributes from the calling
     process:

	  nice value [see nice(2)]
	  process ID
	  parent process ID
	  process group ID
	  real user and group IDs
	  supplementary groups IDs [see getgroups(2)]
	  semadj values [see semop(2)]
	  session ID [see exit(2) and signal(2)]
	  trace flag [see ptrace(2) request 0]
	  time left until an alarm clock signal [see alarm(2)]
	  interval timers [see getitimer(2)]
	  current working directory
	  root directory
	  file mode creation mask [see umask(2)]
	  file size limit [see ulimit(2)]
	  resource limits [see getrlimit(2)]
	  utime, stime, cutime, and cstime [see times(2)]

									Page 4

exec(2)								       exec(2)

	  file-locks [see fcntl(2) and lockf(3C)]
	  controlling terminal
	  process signal mask [see sigprocmask(2)]
	  pending signals [see sigpending(2)]

     Upon successful completion, exec marks for update the st_atime field of
     the file.	Should the exec succeed, the process image file is considered
     to have been open()-ed.  The corresponding close() is considered to occur
     at a time after this open, but before process termination or successful
     completion of a subsequent call to exec.

     exec will fail and return to the calling process if one or more of the
     following are true:

     EACCES	   Search permission is denied for a directory listed in the
		   new process file's path prefix.

     EACCES	   The new process file is not an ordinary file.

     EACCES	   Execute permission on the new process file is denied.

     E2BIG	   The number of bytes in the new process's argument list is
		   greater than the system-imposed limit {ARG_MAX} [see
		   sysconf(2), intro(2), and limits.h].	 The argument list
		   limit is the sum of the size of the argument list plus the
		   size of the environment's exported shell variables.

     E2BIG	   The number of bytes in the first line of an interpreter
		   file is greater than 256 bytes.

     EAGAIN	   Not enough memory.

     EFAULT	   An argument points to an illegal address.

     ELIBACC	   Required shared library does not have execute permission.

     ELIBEXEC	   Trying to exec(2) a shared library directly.

     ELIBMAX	   The required number of shared libraries exceeds the system
		   imposed maximum {SHLIB_MAX} [see intro(2)].

     ELOOP	   Too many symbolic links were encountered in translating
		   path or file.

     ENAMETOOLONG  The length of the file or path argument exceeds {PATH_MAX},
		   or the length of a file or path component exceeds
		   {NAME_MAX} while _POSIX_NO_TRUNC is in effect.

     ENOENT	   One or more components of the new process path name of the
		   file do not exist or is a null pathname.

									Page 5

exec(2)								       exec(2)

     ENOTDIR	   A component of the new process path of the file prefix is
		   not a directory.

     ENOEXEC	   The exec is not an execlp or execvp, and the new process
		   file has the appropriate access permission but an invalid
		   magic number in its header.

     ENOEXEC	   The executable object file has badly formed header
		   information.

     ENOEXEC	   The requested virtual addresses are not available.

     ENOMEM	   The new process requires more virtual space than is allowed
		   either by the system-imposed maximum or the process imposed
		   maximum {PROCSIZE_MAX} [see getrlimit(2) and intro(2)].

     EPERM	   A non-superuser attempts to execute a setuid or setgid
		   shell script with a uid or gid which is different than the
		   user's effective uid/gid, and the configured value for
		   nosuidshells is non-zero (the default) [see intro(2) and
		   lboot(1M)].

SEE ALSO
     ps(1), sh(1), lboot(1M), intro(2), alarm(2), exit(2), fcntl(2), fork(2),
     getgroups(2), getrlimit(2), nice(2), pcreate(2), ptrace(2), semop(2),
     sigaction(2), signal(2), sigpending(2), sigprocmask(2), sigset(2),
     sproc(2), sysconf(2), times(2), ulimit(2), umask(2), lockf(3C),
     signal(3B), sigvec(3B), stdio(3S), system(3S), a.out(4), proc(4),
     environ(5)

DIAGNOSTICS
     If exec returns to the calling process, an error has occurred; the return
     value is -1 and errno is set to indicate the error.

									Page 6

[top]

List of man pages available for IRIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net