Re: Change in behaviour regarding subshell handling?
I noticed that bash has changed behaviour regarding subshell handling, breaking a script of mine. Now a script with -e fails when a subshell fails whereas it didn't before. I looked at the CHANGES file and couldn't find anything about this, so I wanted to ask if this change was intentional or if this is a bug. In fact, there's something in CHANGES that might be relevant but the description isn't really clear at all: l. Changed behavior of shell when -e option is in effect to reflect consensus of Posix shell standardization working group. This behavior is one of the consequences of the Austin Group's interpretation. Failures of user-specified subshells cause the shell to exit when set -e is in effect. The key piece of the interpretation was to widen the scope of commands that cause the shell to exit without an explicit exception from simple commands to all commands. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Change in behaviour regarding subshell handling?
* Chet Ramey chet.ra...@case.edu [2009-09-24 08:29]: l. Changed behavior of shell when -e option is in effect to reflect consensus of Posix shell standardization working group. This behavior is one of the consequences of the Austin Group's interpretation. Failures of user-specified subshells cause the shell to exit when set -e is in effect. The key piece of the interpretation was to widen the scope of commands that cause the shell to exit without an explicit exception from simple commands to all commands. Thanks for the confirmation. Maybe CHANGES can be updated to list all the changes that were made as a consequence of the Austin Group's interpretation. -- Martin Michlmayr http://www.cyrius.com/
Re: Change in behaviour regarding subshell handling?
Thanks for the confirmation. Maybe CHANGES can be updated to list all the changes that were made as a consequence of the Austin Group's interpretation. Here's the new description of set -e: -e When this option is on, when any command fails (for any of the reasons listed in [xref to 2.8.1] or by returning an exit status greater than zero) the shell immediately shall exit with the following exceptions: 1) The failure of any individual command in a multi-command pipeline shall not cause the shell to exit. Only the failure of the pipeline itself shall be considered. 2) The -e setting shall be ignored when executing the compound list following the while, until, if, or elif reserved word, a pipeline beginning with the ! reserved word, or any command of an AND-OR list other than the last. 3) If the exit status of a compound command other than a subshell command was the result of a failure while -e was being ignored, then -e shall not apply to this command. This requirement applies to the shell environment and each subshell environment separately. For example, in set -e; (false; echo one) | cat; echo two the false command causes the subshell to exit without executing echo one; however, echo two is executed because the exit status of the pipeline (false; echo one) | cat is zero. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Change in behaviour regarding subshell handling?
I noticed that bash has changed behaviour regarding subshell handling, breaking a script of mine. Now a script with -e fails when a subshell fails whereas it didn't before. I looked at the CHANGES file and couldn't find anything about this, so I wanted to ask if this change was intentional or if this is a bug. In fact, there's something in CHANGES that might be relevant but the description isn't really clear at all: l. Changed behavior of shell when -e option is in effect to reflect consensus of Posix shell standardization working group. Anyway, the test program and output is below. Take this script: set -e set -x echo 1 (echo x | grep -v x) echo 2 On Debian lenny with 3.2.39(1)-release: foobar:~# bash t + echo 1 1 + grep -v x + echo x + echo 2 2 On Debian testing with 4.0.28(1)-release: foobar:~# bash t + echo 1 1 + echo x + grep -v x With dash (same output for lenny and testing): foobar:~# dash t + echo 1 1 + echo x + grep -v x + echo 2 2 -- Martin Michlmayr http://www.cyrius.com/
