Date: Mon, 29 Feb 2016 18:03:23 -0500
From: "James K. Lowden" <jklow...@schemamania.org>
Message-ID: <20160229180323.c5ab8c3d112b02477e9aa...@schemamania.org>
| Similarly, we want,
|
| > build_and_run command-that-should-not-fail ||
| > mail -s help kre </dev/null
|
| to evaluate as
|
| (build_and_run command-that-should-not-fail) ||
| mail -s help kre </dev/null
|
| (except of course for side effects of build_and_run).
That's an interesting possibility, I might look at that and see
whether or not it is reasonable to make that happen.
Of course, if we did that it would mean that anyone writing scripts
using functions and using "set -e" on NetBSD would be writing non-portable
scripts.
For anyone who can't see from this what James is suggesting (it took me
a little time to figure it out...) the idea would be, if I am understanding
correctly, that while executing a function, if "set -e" is in effect, and
a command is executed in a fashion where the rules do not cause set -e
to be ignored, then the function should return a failure status immediately,
and execute no more (of its) commands. That is, the set -e would cause
a "return $?" rather than "exit $?" in this case. The same would apply to
scripts executed with the "." command, which have many similarities to
functions.
What that will do to the shell calling the function depends upon whether -e
was enabled there or not (it may have been enabled only inside the function)
and the context in which the function call was made.
That seems reasonable to me, if I can make it work (no promises for an
early attempt at that, there are other bugs and issues more pressing than
dealing (more) with set -e...)
| 2. For X && Y constructions, evaluate as if "X; then Y; fi".
That's what we have now, so nothing to do there. I suspect, that aside
from the function and '.' command cases, the way "set -e" is defined and
works now, is largely what people who are writing scripts really expect
and want. (As distinct from those just attempting to torture test "set -e".)
| It just seems to me that when Posix is providing lousy guidance,
| innovation is better then emulation.
I suspect that possibly no-one had considered this method before, certainly
no-one that I am aware of has implemented it - and as well as telling
implementors what to implement, probably even more importantly, the standard
is supposed to tell users what they can expect to work in a conforming shell.
It would actually be wrong of the standard to specify something that no-one
implements - that is not what a standard is (it is not legislation.)
So, the way the standard gets updated, is that we (or someone) does this,
it seems to work well for us (or them), and gets copied by other shells.
Once several shells have followed along, the standard is likely to change
to make the behaviour either unspecified, or implementation defined.
That still means that users cannot rely upon it, but opens the door for
other shells, which for whatever reason, do not want to deviate from the
standard, to also implement it the new way. Once (almost) all shells
have converted (if that ever happens) then the standard can be updated
again to specify that this is what happens.
That's how standards development works (or should). And yes, it is
a very slow process.
So don't just always blame posix when it specifies something that seems
insane - often it is specified that way because that's how shells (or
whatever) have actually implemented it. Not always, sometimes it is
just because whoever wrote the text didn't realise what their words
were actually saying... (in that case you can blame posix, and people do.)
kre
