Eric Blake wrote:
On 01/30/2012 02:27 PM, Linda Walsh wrote:
Chet Ramey wrote:
As Eric said, the other parts of the Posix description make it clear that
the `ignoring set -e' status is inherited by subshells.
----
The original POSIX standard made this clear -- in that
it was only a failure of a 'simple' command that resulted' in
an err-exit'.
Have you not read the link I pointed to? The whole point of
[1]http://austingroupbugs.net/view.php?id=52 is a claim that the POSIX 2001
wording for 'set -e' was buggy, because it was inconsistent with
traditional practice, and therefore that particular bug report provides
the approved TC1 wording for how 'set -e' must behave, when using only
the shell features documented by POSIX.
---
A A A The buggy behavior they mentioned had to do with pipes and
subshells.
Then they changed *multiple behaviors* related to "-e", some of which
were
unrelated to the problem they mentioned.
The initial implementation of "-e" was to catch programs that returned
with
non-zero return values so that if you didn't check for them, the
program would
abort.
It was never intended to cause internal shell commands to fail in the
same
way.A The Shell, would know if an error condition had occurred, and
wouldn't
need a global-catch-all switch like "-e", to flag an error.
Example
let a=0
or ((a=0))
The shell would know that an internal math calculation setting a
variable to zero Cannot be an error.A Thus it would never be flaggedA
as an error.
This is the wording of the Austin committee has done -- it has made the
Shell
appear stupid.A -- because the writers of that spec were unthinking
and
didn't restrict their changes to the specific problem at hand.A They
broke
existing practice and broke the existing POSIX SPEC, by creating a new
and incompatible spec, -- that IS NOT POSIX compatible.
Adhering to orders that are wrong, because "it's the 'standard', didn't
work for
Nazi officers, some excuse for not using their brain an realizing theA
'rules' or standard as stated IS wrong.
They even screwed up their example about using "-e" in functions...
They should say not to rely -e in function but instead have shown an
example of
how to use it.
For example - any shell function including my stdlib.shlib,A (which I
won't
claim is bugfree, bug this part did work).
and does
function xxx {
DebugPushA <DebugClass>
....
#before any exit -
DebugPop
}
would have the value of "-e" preserved if that was turned on --
preserving it
into function calls as specified for the specific 'DebugClass'...(as
well as
other Debug options, tracing, (-x), for example).A Not only might they
be preserved, but the flags could be toggled on/off per class. so
-e/-x/-u would pop on for some classes, or off for others, regardless
of globally set flags.
But they stupidly say "just don't use this 'potentially' valuable
development feature, instead well will provide '/dev/null'.A
(Nothing).A A The ethics and morality of those who choose to destroy
and not create replacement, is no greater than that of the arsonist or
architect of destruction - it's simply a matter of 'scale'.
If bash brainlessly complies with brainless orders, then it is fully
responsible for choosing to be brainless.A The same goes for any sheep
who stupidly follow practices without examining details -- like closing
out bugs as 'knee jerk' standard practice' without even examining
recent release notes to note that the
area the bug cropped up in was something that was rewritten with some
incompatible behavior changes.A But that would require responsible and
thoughtful behavior, something that you don't see in the the software
world today.
Everything is about following the path of least resistance and going
for whatever is easiest and cheapest, because it's a race to the
bottom, for quality and features.
Meanwhile the same companies pushing for 0-incremental costs on
software, are those that are pushing for harsher penalties for those
who freely duplicate such software (or content)...A
I see the whole thing as a related and intertwined pathology that is,
in the long run, antithetical to human existence and survival.
More people need to stop being part of the problem and realize that
just because some people say things that don't appear to be pleasant,
doesn't mean they are not true -- they may simply lack the ability to
dissemble as well as others -- a
large disadvantage in today's society.
The Autin's groups pronouncements broke POSIX to the point that I don't
consider their pronouncements to be posix compatible and software that
tries to follow the parts of their docs that reduce functionality *and*
conflict with the original (not due to security faults) are equally
broken.
-l
References
1. http://austingroupbugs.net/view.php?id=52
