Thus spake Robert Elz ("RE> ") sometime Tomorrow...
RE> As Ben Harris (I think) pointed out earlier, someone has to end up being
RE> amazed, sometimes, here. Given two (non-grouped) command lines
RE>
RE> false
RE> false && echo foo
RE>
RE> and the two (grouped) "equivalent" commands
RE>
RE> (false)
RE> (false && echo foo)
RE>
RE> There's no way to make the two pairs behave the same in both cases,
RE> without requiring absolutely absurd things of the shell.
The really screwy thing here is that if I do this:
rivendell 511: bash -e
bash-2.05$ (false)
bash-2.05$ echo $?
1
bash-2.05$
Interesting that I get a non-zero exit back, but the shell does not
terminate.
To me, this is SO bloody inconsistent as to be very frustrating, but
I'll attribute it for the moment to being under the weather and a lot
of other pressures, so ignore that :-).
RE> | or so counter-intuitively defined
RE>
RE> I don't believe it is that either.
I think it is. To have () behave differently than a raw command
just because it's ()d makes zero sense.
It turns out that a failed () still returns an exit status, so perhaps
"|| exit $?" might be the most useful solution after all (for some strange
definition of "useful" with which I was not previously acquainted).
RE> | or so inconsistently implemented
RE>
RE> I don't even believe it is that - rather, I simply don't believe that
RE> anyone is doing much in the way of serious maintenance on the SysV
RE> shells, to update them to POSIC conformance (the BSD world has changed
RE> lots of code which wasn't POSIX - where changed affected SysV, relatively
RE> little has been done). Of course, that's partly because none of the
RE> commercial vendors can afford to be in any way not bug-for-bug compatible
RE> with everyone else, it is almost impossible to ever simply change something
RE> as a solitary vendor. It is just the (many vendors of) the Sys V shells
RE> that are behaving differently - just about every other (independently
RE> created) shell is doing things the POSIX way.
Okay, I'll buy that.
RE> | that portable scripts and makefiles should not rely on it.
RE>
RE> This I absolutely agree with. But mostly because it is a dumb idea,
RE> regardless of its actual specification.
How would you have something run, then, that drops instantly dead in its
tracks? Should you be required to jump through hoops to make that happen?
Does make(1) need a redesign (again)?
What's POS-ix have to say about "${var:?val}", by the way?
--*greywolf;
--
NetBSD: The Final Frontier.