In a bash script, what is the difference between the line `exec >>/var/log/job.log 2>&1` and the line `exec /usr/bin/myjob`?

## One builtin, two behaviours `exec` is a bash builtin whose behaviour hinges on whether a command word follows it. **With a command** — `exec /usr/bin/myjob` — bash does not create a new process. Normally, running an external command means bash makes a child and the child becomes that program; `exec` skips the child and turns *this* process into the program directly. The consequences follow from that one fact: - The PID is unchanged. Whatever was watching the shell — a supervisor, a container runtime, a parent script's `wait` — is now watching `myjob` under the same number. - Open file descriptors, the current directory and the exported environment carry over, because they are properties of the process and the process survived. - Everything that was purely *shell* state is gone: functions, non-exported variables, aliases and traps existed only inside bash's memory, and that memory has been replaced. - Nothing after the `exec` line runs. Not the next command, not an `EXIT` trap, not a cleanup function. The script does not "return" from `exec`. ```bash trap 'echo cleanup' EXIT exec /bin/true # the trap never fires; bash is gone echo "unreachable" ``` **Without a command** — `exec >>/var/log/job.log 2>&1` — there is nothing to replace the shell with, so bash keeps running and just performs the redirections on itself. Ordinarily a redirection lasts only for the command it is attached to; applied through `exec`, it changes the shell's own descriptors, so every later command in the script inherits the new destination. This is the standard opening move for a script that must log unattended: ```bash #!/usr/bin/env bash exec >>/var/log/job.log 2>&1 echo "starting run at $(date)" # lands in the log, as does everything after it ``` The detailed mechanics of duplicating and saving descriptors — numbering, `n>&m`, restoring what you replaced — are a topic of their own; what matters here is the *scope* change: from one command to the whole shell. ## Why the replacing form exists Three recurring reasons: 1. **Handing off cleanly.** A wrapper script sets up environment, resolves configuration, then `exec`s the real program. Without `exec` you keep an idle bash sitting in the process tree for the entire lifetime of the program, doing nothing but waiting, and standing between the program and whoever signals it. 2. **Keeping the identity.** Supervisors, container runtimes and anything tracking a PID keep tracking the right process, because there is only ever one process. 3. **Saving a process.** Marginal on a desktop, real when a script fans out thousands of short-lived invocations. ## Failure and options If the command cannot be executed, a **non-interactive** shell exits — `exec` is not a normal command whose failure you can shrug off. `shopt -s execfail` changes that: a non-interactive shell will not exit when `exec` fails, so the script can fall back to another path. Without it, an `exec` of a mistyped binary ends the script on the spot. `exec` also takes a few options worth knowing: `-a name` runs the program with a different `argv[0]` (which is what shows up in a process listing), `-c` runs it with an empty environment, and `-l` puts a dash in front of `argv[0]` the way a login shell is started. ## The trap that surprises people Because `exec cmd` destroys the shell, any cleanup you registered with `trap ... EXIT` is silently abandoned. A script that creates a temporary directory, registers a trap to remove it, and then `exec`s the real program will leave that directory behind forever. Either do the cleanup before the `exec`, or do not `exec` at all and let the shell stay alive to run its trap — accepting the extra process and taking responsibility for forwarding signals to the child. ## Reading it in review When you see `exec` in a script, first check for a command word. No command word means "the rest of this script's output goes somewhere else", and you keep reading. A command word means "this script ends here", and everything below it is dead code — which, in a review, is worth flagging as a bug in itself.