Why does ( exit 1 ) not exit the script?
()
runs commands in the subshell, so by exit
you are exiting from subshell and returning to the parent shell. Use braces {}
if you want to run commands in the current shell.
From bash manual:
(list) list is executed in a subshell environment. Variable assignments and builtin commands that affect the shell's environment do not remain in effect after the command completes. The return status is the exit status of list.
{ list; } list is simply executed in the current shell environment. list must be terminated with a newline or semicolon. This is known as a group command. The return status is the exit status of list. Note that unlike the metacharacters ( and ), { and } are reserved words and must occur where a reserved word is permitted to be recognized. Since they do not cause a word break, they must be separated from list by whitespace or another shell metacharacter.
It's worth mentioning that the shell syntax is quite consistent and the subshell participates also in the other ()
constructs like command substitution (also with the old-style `..`
syntax) or process substitution, so the following won't exit from the current shell either:
echo $(exit)
cat <(exit)
While it may be obvious that subshells are involved when commands are placed explicitly inside ()
, the less visible fact is that they are also spawned in these other structures:
command started in the background
exit &
doesn't exit the current shell because (after
man bash
)If a command is terminated by the control operator &, the shell executes the command in the background in a subshell. The shell does not wait for the command to finish, and the return status is 0.
the pipeline
exit | echo foo
still exits only from the subshell.
However different shells behave differently in this regard. For example
bash
puts all components of the pipeline into separate subshells (unless you use thelastpipe
option in invocations where job control is not enabled), but AT&Tksh
andzsh
run the last part inside the current shell (both behaviours are allowed by POSIX). Thusexit | exit | exit
does basically nothing in bash, but exits from the zsh because of the last
exit
.coproc exit
also runsexit
in a subshell.
Executing the exit
in a subshell is one pitfall:
#!/bin/bash
function calc { echo 42; exit 1; }
echo $(calc)
The script prints 42, exits from the subshell with return code 1
, and continues with the script. Even replacing the call by echo $(CALC) || exit 1
does not help because the return code of echo
is 0 regardless of the return code of calc
. And calc
is executed prior to echo
.
Even more puzzling is thwarting the effect of exit
by wrapping it into local
builtin like in the following script. I stumbled over the problem when I wrote a function to verify an input value. Example:
I want to create a file named "year month day.log", i.e., 20141211.log
for today. The date is input by a user who may fail to provide a reasonable value. Therefore, in my function fname
I check the return value of date
to verify the validity of the user input:
#!/bin/bash
doit ()
{
local FNAME=$(fname "$1") || exit 1
touch "${FNAME}"
}
fname ()
{
date +"%Y%m%d.log" -d"$1" 2>/dev/null
if [ "$?" != 0 ] ; then
echo "fname reports \"Illegal Date\"" >&2
exit 1
fi
}
doit "$1"
Looks good. Let the script be named s.sh
. If the user calls the script with ./s.sh "Thu Dec 11 20:45:49 CET 2014"
, the file 20141211.log
is created. If, however, the user types ./s.sh "Thu hec 11 20:45:49 CET 2014"
, then the script outputs:
fname reports "Illegal Date"
touch: cannot touch ‘’: No such file or directory
The line fname…
says that the bad input data has been detected in the subshell. But the exit 1
at the end of the local …
line is never triggered because the local
directive always return 0
. This is because local
is executed after $(fname)
and thus overwrites its return code. And because of that, the script continues and invokes touch
with an empty parameter. This example is simple but the behavior of bash can be quite confusing in a real application. I know, real programmers don't use locals.☺
To make it clear: Without the local
, the script aborts as expected when an invalid date is entered.
The fix is to split the line like
local FNAME
FNAME=$(fname "$1") || exit 1
The strange behavior conforms to the documentation of local
within the man page of bash: "The return status is 0 unless local is used outside a function, an invalid name is supplied, or name is a readonly variable."
Though not being a bug I feel that the behaviour of bash is counterintuitive. I am aware of the sequence of execution, local
should not mask a broken assignment, nevertheless.
My initial answer contained some inaccurancies. After a revealing and in-depth discussion with mikeserv (thank you for that) I went for fixing them.
The actual solution:
#!/bin/bash
function bla() {
return 1
}
bla || { echo '1'; exit 1; }
echo '2'
The error grouping will only execute if bla
returns an error status, and exit
is not in a subshell so the whole script stops.