exec 1 user commands nosh 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 nosh1. exec is a chain-loading utility that simply chain loads to next-prog with the execvp3 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. This option is for compatibility with the built-in exec1 command of shells. Avoid its use. Instead, use the built-in clearenv1 command. 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 login1. 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 exec1 and in nosh1. 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 execv1.) The built-in command mechanism tries to ensure that the COMM and ARGS fields shown in a ps1 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: chdir1 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. Jonathan de Boyne Pollard