bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: set -e in (subshells) does not work independently of outer context


From: Linda Walsh
Subject: Re: set -e in (subshells) does not work independently of outer context
Date: Wed, 08 Feb 2012 15:31:54 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666

   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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]