exec — chain
exec [--login] [--clear] [--arg0 string] {next-prog}
Most shells have a built-in exec command that replaces the shell process itself. See the manual for each individual shell for its built-in command. This command will be an external command to most shells. It is a built-in command for nosh(1).
exec is a chain-loading utility that simply chain loads to next-prog with the execvp(3) function.
next-prog may contain its own command line options, which exec will ignore.
If the --clear command line option is used, exec will clear its environment before chaining. Otherwise, it leaves its process state unchanged.
The --arg0 command line option causes it to replace the first element of the argument list that it passes to next-prog, which is otherwise the name of the command in next-prog, with the supplied string.
If the --login command line option is used, then the first element of the argument list has a dash (-) prepended, which is the convention for signalling shells that they are being invoked directly by login(1).
This happens after any substitution because of --arg0 .
exec is in fact a multiple personality program, whose function varies according to what name it is invoked as. The alternative names are: appendpath, background, cd, chdir, chdir-home, chroot, clearenv, cyclog, delegate-control-group-to, envdir, envgid, envuidgid, erase-machine-id export-to-rsyslog, false, fdmove, fdredir, fifo-listen, follow-log-directories, foreground, getuidgid, hardlimit, klog-read line-banner, local-datagram-socket-listen, local-seqpacket-socket-accept, local-seqpacket-socket-listen, local-stream-socket-accept, local-stream-socket-connect, local-stream-socket-listen, machineenv, make-private-fs, make-read-only-fs, monitored-fsck, create-control-group, move-to-control-group, netlink-datagram-socket-listen, nosh, oom-kill-protect, pause, pipe, plug-and-play-event-handler prependpath, printenv, read-conf, recordio, set-control-group-knob, set-dynamic-hostname, set-mount-object setenv, setgid-fromenv, setlock, setpgrp, setsid, setsid, setuidgid-fromenv, setuidgid, setup-machine-id softlimit, syslog-read tai64n, tai64nlocal, tcp-socket-accept, tcp-socket-connect, tcp-socket-listen, tcpserver true, ucspi-socket-rules-check, udp-socket-connect, udp-socket-listen, ulimit, umask, unsetenv, unshare, userenv, and userenv-fromenv. See their individual manual pages for details.
These other commands are also available as built-in commands, in exec(1) and in nosh(1).
If next-prog is such a command, it will be executed directly, without needing to ask the operating system to overlay the current process and reinitialize the runtime libraries.
(Built-in commands must be named simply, and may not have directory prefixes.
If invoked with prefixes, they will be run as ordinary overlaid programs via execv(1).)
The built-in command mechanism tries to ensure that the COMM and ARGS fields shown in a ps(1) listing reflect the changes when chain-loading through built-in commands.
Having built-in commands, rather than forcing each individual command to be reloaded as a fresh process image by the operating system, exposes all built-in commands in a chain-loading chain to any weaknesses in one.
However, this is a reasonable trade-off. Most of the built-in commands do very little, and most of their processing when executed as external commands is in fact devoted to the dynamic loader and initializing the runtime libraries. (For example: chdir(1) makes two system calls in the meat of the command. On one Linux system, however, the dynamic loader and runtime libraries make 143 system calls just to load and start the program. Other commands have similarly enormous ratios.) Having built-in commands eliminates the repeated teardown and re-initialization overheads from the dynamic loader and runtime libraries, reducing the overhead of small commands that individually do little to the same order of magnitude as simple function calls.
And the commands themselves are short and readily amenable to security audit.
They are highly modular, with almost no coupling between commands; and usually simple.
And you can always run the commands as external commands, as aforementioned.