set -e in bash 4

[Tobias Poschwatta]

In the following test case test1.sh, bash 4 behaves differently from
bash 3.1. The behaviour of bash 3.1 is what I would expect to be
correct.  Is this a bug in bash 4 or an intentional change?

Using bash 4:

$ /bin/bash --version
GNU bash, version 4.0.28(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ ls
test1a.sh  test1.sh  test2.sh
$ cat test1.sh
( set -e; . ./test2.sh ) || exit 1
echo done
$ cat test2.sh
echo 1
false
echo 2

$ cat test1a.sh
( set -e; . ./test2.sh )
echo done
$ /bin/bash test1.sh
1
2
done
$ /bin/bash test1a.sh
1
done


Using bash 3.1.17:

$ /bin/bash --version
GNU bash, version 3.1.17(2)-release (i486-slackware-linux-gnu)
Copyright (C) 2005 Free Software Foundation, Inc.
$ /bin/bash test1.sh
1
$ /bin/bash test1a.sh
1
done


Thanks,
Tobias

[Marc Herbert-6]

Tobias Poschwatta a écrit :
> In the following test case test1.sh, bash 4 behaves differently from
> bash 3.1. The behaviour of bash 3.1 is what I would expect to be
> correct.  Is this a bug in bash 4 or an intentional change?

Isn't this related to this change?
http://thread.gmane.org/gmane.comp.shells.bash.bugs/13465

[Chet Ramey]

Tobias Poschwatta wrote:

> In the following test case test1.sh, bash 4 behaves differently from
> bash 3.1. The behaviour of bash 3.1 is what I would expect to be
> correct.  Is this a bug in bash 4 or an intentional change?
>
> Using bash 4:
>
> $ /bin/bash --version
> GNU bash, version 4.0.28(1)-release (x86_64-pc-linux-gnu)
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> $ ls
> test1a.sh  test1.sh  test2.sh
> $ cat test1.sh
> ( set -e; . ./test2.sh ) || exit 1
> echo done
> $ cat test2.sh
> echo 1
> false
> echo 2
>
> $ cat test1a.sh
> ( set -e; . ./test2.sh )
> echo done
> $ /bin/bash test1.sh
> 1
> 2
> done
> $ /bin/bash test1a.sh
> 1
> done

Yes, this is the intended behavior.  This is one of the things that
came out of the discussions among the Posix working group.  It also
matches historical practice.  Ironically, one of the examples we used
while discussing the issue is very close to yours.

Chet

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@...    http://cnswww.cns.cwru.edu/~chet/

[Tobias Poschwatta]

On Wed, Oct 21, 2009 at 09:56:49PM -0400, Chet Ramey wrote:
> Yes, this is the intended behavior.  

Thanks for clarifying.

> This is one of the things that
> came out of the discussions among the Posix working group.  It also
> matches historical practice.  

I searched the archives and found this thread from Feb 2009.
  http://thread.gmane.org/gmane.comp.standards.posix.austin.general/282

> Ironically, one of the examples we used
> while discussing the issue is very close to yours.

Indeed, very close:
 http://thread.gmane.org/gmane.comp.standards.posix.austin.general/282/focus=283
David Korn gave this example:

  ... it might seem strange that -e cannot be reenabled, but all
  shells seem to follow this historic practices, so that
        sh -ce '(set -e;false;echo good) || echo bad'
  outputs good.


Thanks,
Tobias