Date: Mon, 29 Feb 2016 16:09:24 +0000
From: Taylor R Campbell <campbell+netbsd-tech-userle...@mumble.net>
Message-ID: <20160229160830.2c36960...@jupiter.mumble.net>
| I think all that James meant was that when executing `false && false'
| or `false && true' as a top-level command, that whole `&&' term should
| return nonzero -- and hence cause the script to fail as a top-level
| command -- because the first subterm, `false', returns nonzero.
Yes, I understood that, but it really is not what you want. If you
start thinking about this from the specification of -e, trying to
understand what it does, and how it should behave, then your (and James')
view is very likely the conclusion you'd reach.
But in real life, when we aren't writing stuff like "false && false" or
"false && true", when someone writes a command like
$x_option && command implementing -x
they aren't asserting that "${x_option}" is supposed to always be
true, and that the script should abort if that is not the case,
what they are doing is making a one line version of
if $x_option
then
command implementing -x
fi
That idiom is endemic, and causing "x && y" to mean anything different
than the "if" equivalent (in any sense at all) would break large numbers
of scripts. Similarly for the || case, but with a "!" after the "if".
So, we make the two exactly equivalent, having -e on does not cause the
"if" version to abort, and no-one ever says it should, so the same must
be true of the '&&' version as well, or we would all have to stop using
that idiom, and the && and || operators would be (in practice) relegated
to be used only in places where their return code is going to be tested.
That would be a pity. Fortunately, I am fairly sure the standards writers
(and shell implementors) are not going to let that happen.
kre
