shell &&, || constructs (really /bin/sh -e behaviour)
Leo de Wit
leo at philmds.UUCP
Wed Oct 5 17:56:25 AEST 1988
In article <639 at eiger.iis.UUCP> prl at iis.UUCP (Peter Lamb) writes:
[ ]...
|And just to support Chris' case that sh -e should not exit if the
|command in a conditional returns non-zero status;
|
|if you have a conditional, it is usually because you *EXPECT* the
|thing to fail sometimes, otherwise you wouldn't have bothered!
Of course, but you must take two other things into account:
1) the conditional is not the exit status of a (1) command, but of a
command list. I can even write something down like:
if
<shell script here>
then
<other stuff here>
fi
and put a whole shell script into the conditional clause (not that this
is common practice). Now do you want -e to be turned off for the whole
clause (see also beneath) ??
2) -e is used when successfull execution of the commands in a script is
a must; take for instance the 'Make' example. Why would the commands in
the commandlist of a conditional clause suddenly be all that different?
If they are, they should be executed by a different shell (my humble
opinion).
A minimal change to the meaning of -e could add the functionality
required without hardly breaking existing code (i.e. the code that
already depends on shells that turn off -e for conditionals):
The last command of the conditional clause's command list should not
cause an exit if it fails and -e is set.
a) Since most clauses are just a simple command (e.g. test) this works
OK in these cases.
b) The change allows termination of the script on all other commands in
the command list, thus respecting the meaning of -e.
c) If you don't want the b)-haviour, there are some alternatives:
you can execute the commands in a subshell; note that this has to
provide for a means of turning off -e which the BSD /bin/sh doesn't
seem to have, since -e is inherited.
Invoking this shell by sh -c seems to avoid this problem:
if sh -c "<non-critical commands here>"; then etc; fi
Just some oil to keep the fire bourning... 8-)
Leo.
More information about the Comp.unix.questions
mailing list