>Number:         9265
>Category:       bin
>Synopsis:       /bin/sh behaviour after "set -e" is inconsistent
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 21 06:39:00 2000
>Last-Modified:
>Originator:     Urban Boquist
>Organization:
Carlstedt Research & Technology AB, Sweden
>Release:        NetBSD-current 2000-01-17
>Environment:
System: NetBSD iller 1.4P NetBSD 1.4P (ILLER) #0: Fri Jan 21 00:43:42 CET 2000 root@iller:/usr/src/sys/arch/i386/compile/ILLER i386


>Description:
A simple shell script (named "3" below) produces different behaviour
when run with NetBSD's /bin/sh compared to either /bin/ksh or
/usr/pkg/bin/bash. I'm not 100% sure that this in itself is a bug (the
sh man page is not very clear about the intended behaviour).

However, even if /bin/sh is supposed to behave different than ksh and
bash in this regard there must still be some bug in /bin/sh because it
is not behaving like that consistently (see the scripts named "1" and
"2" below).

>How-To-Repeat:

See the following transcript, the three scripts all produce the output
"haha" when run with either ksh or bash (or Solaris /bin/sh), but with
NetBSD's /bin/sh only the first two produces "haha".

$ cat 1
#!/bin/sh
set -x
set -e
false && false
echo haha
$ ./1
+ set -e
+ false
+ echo haha
haha
$ 
$ cat 2
#!/bin/sh
set -x
set -e
case foo in
    foo) false && false
	 echo haha ;;
esac
$ ./2
+ set -e
+ false
+ echo haha
haha
$ 
$ cat 3
#!/bin/sh
set -x
set -e
set -- foo
case $1 in
    foo) shift
	 false && false
	 echo haha ;;
esac
$ ./3
+ set -e
+ set -- foo
+ shift
+ false
$ 

It seems like all the constructs "case" + arguments + "shift" + "&&"
are necessary to trigger the behaviour in "3", without the shift it
will print "haha". Without the "&&" it will not print "haha", but
neither will ksh nor bash.

For reference, the /bin/sh manpage says:

           -e errexit       If not interactive, exit immediately if any
                            untested command fails.  The exit status of a com-
                            mand is considered to be explicitly tested if the
                            command is used to control an if, elif, while, or
                            until; or if the command is the left hand operand
                            of an ``&&'' or ``||'' operator.

So as I see it: either "3" shows a bug, or both "1" and "2" show a
bug. The latter would make /bin/sh different from both ksh and bash
(and Solaris /bin/sh).

>Fix:
Sorry, no idea.
>Audit-Trail:
>Unformatted: