exec(2)exec(2)NAME
exec: execl(), execle(), execlp(), execv(), execve(), execvp() - exe‐
cute a file
SYNOPSIS
Remarks
The ANSI C "" construct denotes a variable length argument list whose
optional and required members are given in the associated comment
DESCRIPTION
The system calls, in all their forms, load a program from an ordinary
executable file into the current process, replacing the current pro‐
gram. The path or file argument refers to either an executable object
file or a file of data for an interpreter. In the latter case, the
file of data is also called a script file.
If the calling process is multi-threaded, a call to any of the exec
functions will cause all threads and light weight processes in the
calling process to be terminated and the new executable image to be
loaded and executed. No thread specific data destructor functions are
called. If the function fails and returns to the caller, threads and
light weight processes (LWPs) in the calling process will not be termi‐
nated.
An executable object file consists of a header (see a.out(4)), text
segment, and data segment. The data segment contains an initialized
portion and an uninitialized portion (bss). For and the POSIX shell
(see sh-posix(1)) can be loaded to interpret a script instead. A suc‐
cessful call to does not return because the new program overwrites the
calling program.
When a C program is executed, it is called as follows:
where argc is the argument count and argv is the address of an array of
character pointers to the arguments themselves. As indicated, argc
usually has a value of at least one, and the first member of the array
points to a string containing the name of the file. Exit conditions
from main are discussed in exit(2).
path points to a path name that identifies the executable file contain‐
ing the new program.
file (in or points to a file name identifying the executable file con‐
taining the new program. The path prefix for this file is obtained by
searching the directories passed in the environment variable (see envi‐
ron(5)). The environment is supplied by the shell (see sh(1)). If
file does not have an executable magic number (see magic(4)), it is
passed to the POSIX shell as a shell script.
arg0, ..., argn are one or more pointers to null-terminated character
strings. These strings constitute the argument list available to the
new program. By convention, at least arg0 must be present and point to
a string identical to path or to path's last component.
argv is an array of character pointers to null-terminated strings.
These strings constitute the argument list available to the new pro‐
gram. By convention, argv must have at least one member, and must
point to a string that is identical to path or path's 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 in which the new program runs.
envp is terminated by a null pointer. For and the C run-time start-off
routine places a pointer to the environment of the calling program in
the global cell:
and it is used to pass the environment of the calling program to the
new program.
Multi-threaded applications should not use the environ variable to
access or modify any environment variable while another thread is con‐
currently modifying any environment variable. Calling any function
which is dependent upon any environment variable is considered a use of
the environ variable to access that environment variable.
Open file descriptors remain open, except for those whose close-on-exec
flag is set (see fcntl(2)). The file offset, access mode, and status
flags of open file descriptors are unchanged.
Note that normal executable files are open only briefly when they start
execution. Other executable file types can be kept open for a long
time, or even indefinitely under some circumstances.
The processing of signals by the process is unchanged by except that
signals caught by the process are set to their default values (see sig‐
nal(2)).
If the set-user-ID mode bit of the executable file pointed to by path
or file is set (see chmod(2)), sets the effective user ID of the new
process to the user ID of the executable file. Similarly, if the set-
group-ID mode bit of the executable file is set, the effective group ID
of the process is set to the group ID of the executable file. The real
user ID and real group ID of the process are unchanged. Normally, the
set-user-ID and set-group-ID functions do not apply to scripts; thus,
if or executes a script, the set-user-ID and set-group-ID bits are
ignored, even if they are set. This behavior can be overridden by set‐
ting the kernel tunable to zero.
The saved user ID and saved group ID of the process are always set to
the effective user ID and effective group ID, respectively, of the
process at the end of the whether or not set-user-ID or set-group-ID is
in effect.
The shared memory segments attached to the calling program are not
attached to the new program (see shmop(2)).
Text and data segment memory locks are not passed on to the new program
(see plock(2)).
Profiling is disabled for the new process (see profil(2)).
The process also retains the following attributes:
· current working directory
· file creation mode mask (see umask(2))
· file locks (see fcntl(2)), except for files closed-on-execu‐
tion
· file size limit (see ulimit(2))
· interval timers (see getitimer(2))
· nice value (see nice(2))
· nice value (see parent process ID)
· pending signals
· process ID
· process group ID
· real user ID
· real group ID
· process start time
· real-time priority (see rtprio(2))
· root directory (see chroot(2))
· semadj values (see semop(2))
· session membership
· signal mask (see sigprocmask(2))
· supplementary group IDs
· time left until an alarm clock signal (see alarm(2))
· trace flag (see ttrace(2) request
· and (see times(2))
For a script file, the initial line of a script file must begin with as
the first two bytes, followed by zero or more spaces, followed by
interpreter or interpreter argument, as in:
One or more spaces or tabs must separate interpreter and argument. The
first line should end with either a newline or a null character.
When the script file is executed, the system executes the specified
interpreter as an executable object file. Even in the case of or no
path searching is done of the interpreter name.
The argument is anything that follows interpreter and tabs or spaces.
If an argument is given, it is passed to the interpreter as and the
name of the script file is passed as Otherwise, the name of the script
file is passed as is passed as specified in the call. All other argu‐
ments specified in the call are passed following the name of the script
file (that is, beginning at if there is an argument; otherwise, at
Some interpreters process the interpreter and the argument internally,
and do not provide the interpreter and the argument to the users
script.
If the initial line of the script file exceeds a system-defined maximum
number of characters, fails. The minimum value for this limit is 32.
The set-user-ID and set-group-ID bits are honored for the script but
not for the interpreter.
For an executable object file, the arguments are passed as
...is passed as specified in the call, unless either or is null as
specified, in which case a pointer to a null string is passed as
Security Restrictions
Some or all of the actions associated with this system call may require
privileges. See privileges(5) for more information.
RETURN VALUE
If returns to the calling program, an error has occurred; the return
value is and is set to indicate the error.
ERRORS
If fails and returns to the calling program, is set to one of the fol‐
lowing values:
The number of bytes in the new program's argument list
plus environment is greater than the system-imposed
limit. This limit is at least 5120 bytes on HP-UX
systems.
Read permission is denied for the executable file or inter‐
preter,
and the trace flag (see ttrace(2) request of the
process is set.
Search permission is denied for a directory listed in the exe‐
cutable
file's or the interpreter's path prefix.
The executable file or the interpreter is not an ordinary file.
The file described by
path or file is not executable. A user with the
privilege cannot execute a file unless at least one
access permission bit or entry in its access con‐
trol list has an execute bit set.
path, argv, or envp point to an illegal address. The
reliable detection of this error is implementation
dependent.
A signal was caught during the
system call.
The executable file is incompatible with the architecture on
which the
has been performed, and is presumed to be for a
different architecture. It is not guaranteed that
every architecture's executable files will be rec‐
ognized.
argv points to NULL and null pointer dereferencing is
allowed. In this case, NULL is a valid address,
but is considered an invalid argument.
Too many symbolic links were encountered in translating the path
name.
The executable file's path name
or the interpreter's path name exceeds bytes, or
the length of a component of the path name exceeds
bytes while is in effect.
path points to an empty string.
One or more components of the executable file's path name
or the interpreter's path name do not exist.
The executable file is shorter than indicated by the size values
in
its header, or is otherwise inconsistent. The
reliable detection of this error is implementation
dependent.
The function call is not
or and the executable file has the appropriate
access permission, but there is neither a valid
magic number nor the characters as the first two
bytes of the file's initial line.
The number of bytes in the initial line of a script file
exceeds the system's maximum.
The new process requires more memory than is available or
allowed
by the system-imposed maximum.
A component of the executable file's path prefix
or the interpreter's path prefix is not a direc‐
tory.
The process does not have sufficient privileges.
The executable file is currently open for writing.
WARNINGS
Unsharable executable files are not supported. These are files whose
magic number was produced with the option of (see ld(1)).
It is recommended to use the call in multi-threaded applications to
avoid possible deadlocks.
DEPENDENCIES
HP Process Resource Manager
If the optional HP Process Resource Manager (PRM) software is installed
and configured, the process's process resource group ID is not changed
by See prmconfig(1) for a description of how to configure HP PRM, and
prmconf(4) for the definition of process resource group.
SEE ALSOsh(1), sh-posix(1), kctune(1M), alarm(2), exit(2), fork(2), nice(2),
ttrace(2), semop(2), signal(2), times(2), ulimit(2), umask(2),
a.out(4), acl(5), environ(5), privileges(5), signal(5),
thread_safety(5).
HP Process Resource Manager: prmconfig(1), prmconf(4) in
STANDARDS CONFORMANCEexec(2)