current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 23 down vote favorite
7

I have a script, that does not exit when I want it to.

An example script with the same error is:

#!/bin/bash

function bla() {
    return 1
}

bla || ( echo '1' ; exit 1 )

echo '2'

I would assume to see the output:

:~$ ./test.sh
1
:~$

But I actually see:

:~$ ./test.sh
1
2
:~$

Does the () command chaining somehow create a scope? What is exit exiting out of, if not the script?

share|improve this question
1  
This calls for a single word answer: subshell –  Joshua Dec 11 '14 at 16:27

2 Answers 2

up vote 52 down vote accepted

() runs commands in the subshell, so by exit you are exiting from subshell and returning to 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.

share|improve this answer
5  
Ah. Now to find all the places, where my predecessor used the wrong braces. Thanks for the insight. –  Minix Dec 10 '14 at 13:43
8  
Take careful note of the spacing in the man page: { and } are not syntax, they are reserved words and must be surrounded by spaces, and the list must end with a command terminator (semicolon, newline, ampersand) –  glenn jackman Dec 10 '14 at 16:18
    
Out of interest, does this tend to actually be another process or just a separate environment in an internal stack? I use () a lot for isolating chdirs, and must have been lucky with my use of $$ etc if the former. –  Dan Sheppard Dec 11 '14 at 0:14
3  
@DanSheppard It is another process, but (echo $$) prints parent shell id because $$ is expanded even before subshell is created. In fact printing subshell process id could be tricky, see stackoverflow.com/questions/9119885/… –  jimmij Dec 11 '14 at 0:25
up vote 11 down vote

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.

share|improve this answer
    
Interesting point. Thanks. –  Minix Dec 11 '14 at 7:32
    
@mikeserv: I added an example to show the relevance. –  hermannk Dec 11 '14 at 20:59
    
@mikeserv: Yes, you're right. Even terser. But the pitfall is still there. –  hermannk Dec 11 '14 at 21:11
    
@mikeserv: Sorry, my example was broken. I'd forgotten the test in doit(). –  hermannk Dec 11 '14 at 22:18
    
Let us continue this discussion in chat. –  hermannk Dec 12 '14 at 6:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.