Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!uflorida!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.questions
Subject: Re: shell &&, || constructs
Keywords: exit status
Message-ID: <8611@smoke.ARPA>
Date: 3 Oct 88 07:14:45 GMT
References: <5651@sgistl.SGI.COM> <3741@boulder.Colorado.EDU> <703@necis.UUCP> <826@philmds.UUCP> <13810@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 18

In article <13810@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
-Regarding `set -e': again, beware!  Old versions of /bin/sh will
-exit if the test portion of an `if', `while', or `until' returns
-a nonzero status, if `-e' is set.  (These are fixed in 4.3BSD-tahoe.)
-In addition, `command1 || command2' will exit if command1 fails.
-(It will also exit if command2 fails, but that seems sensible.
-I believe SysV's /bin/sh does *not* exit if command2 fails.  If
-this is considered correct behaviour, let me know, because I just
-`fixed' this to work the way I think seems sensible.)

The correct behavior is for "failure || failure" to count as an error
with respect to "set -e", and the other combinations of operands to ||
to not count as an error.  BRL's SVR2-based shell works this way; I
seem to recall that there was a bug in the eflag handling that had to
be fixed, although it might not have involved || (I don't remember).

Obviously you don't want to make your shell scripts depend on this if
you're concerned about portability.