Re: Intriguing error with arithmetic evaluation

[L. A. Walsh]

Greg Wooledge wrote:
> On Mon, Aug 15, 2016 at 03:15:13AM -0700, L. A. Walsh wrote:
>   
> > Calculations shouldn't ever trigger "-e" except for things like
> > division by 0 (which doesn't trigger it, as the calculation dies
> > before an return value can be calculated); it's counter-intuitive.
> >     
>
> You may wish as hard as you like, but wishing will not change reality.
> The reality is that set -e is worse than useless rubbish.
---
   You can complain about reality, but you not understanding how
"-e" was "useful", only proves your expertise in shell -- *literally*.

   You are programming in shell at a level so far beyond what a
beginner would, you can not understand how it was useful.  FWIW, I don't

example:
 cp a b
 rm a

If I want the script to exit if 'cp' fails, "-e" does that.
No need to write any other error handling.  Would I write it that way?
No.  I'd use

cp a b && rm a    #for the simple case,

but for a script I want to reuse or maintain/keep around, more likely:
 cp a b || die "cp a b died" $?
 rm a || die "rm a died" $?

w/die printing a msg and optionally printing status then forcing
an exit.

or, wrapping the whole command like:
 cmd "cp a b"
 cmd "rm a"

which will eval the cmd & do die.

But beginner scripts, or many scripts from the 80's & 90's and 2000's,
that don't test every exit val and wrap every command, using "-e" was a
primitive way to stop script execution w/out conditionalizing and/or
wrapping every command.

If your subcommands will execute in sub processes -- then
your 'die' command needs to send a SIGKILL or such, to
the parent group.  But would a beginner have a clue about
how to do that?  Not likely. 

Your problem, Greg, is that you are so far ahead of the curve
in your shell-expertise, that you can't admit "-e"'s
usefulness in those situations.  I'm not saying it is a great
idea or should be used in released scripts,
but it was (and is) out there, and beginners did use (and are using it)
in the way it was originally implemented (against simple
commands).

Many 3rd party scripts I've seen, that were band-aid install
scripts or such), -- even into the early 2000's used "-e"
in quick & dirty install scripts that were only executed
once, on install and never used again (one-time-use scripts).

In such situations, "-e" was a lazy or beginner's way of
doing primitive "die-on-unexpected-error checking".

> It makes you THINK you're using some sophisticated advanced scripting language 
> with exception handling...
>   
---
No, it does not.  That's where you are falling into a trap.
I never thought that, and most uses I saw that used that didn't
seem to assume that.  I think that's your "expertise bias" at
play.

> You are using a horrible duct-tape hack from the
> mid-1970s.
>   
---
   Exactly.  It used to be common to acknowledge that the
internet was held together by hacks and duck-tape.  Q.E.D.

   Keeping "-e" semantics in a "bo[e]rn[e]-again-shell"
compatible with the original shell would be the smart way to
go.  POSIX changed it to be incompatible with historical
implementations -- thus, creating a new standard (@Chet), that
was no longer a Portable-OS-IX (IX - Interface/eXchange) as
the original POSIX was stated to be.  You can call the fact
that new POSIX versions after 2001 (maybe 1999) were no longer
*portable* or Xchangeable with previous versions a conspiracy,
but you can't deny that it is so.  The change with "-e" is
an example.

> The sooner you acknowledge that set -e is NOT intended for use in new
> scripts...
----
   Of course it isn't -- since it no longer works in a compatible way
with the older implementation, you can't use it.
>  but instead is ONLY provided to make those old mid-1970s scripts
> continue to "run" the same way today as they did back then, the better
> off you will be.
>   
---
   Wrong -- the older scripts assume it worked only on simple
commands.  POSIX changed that.  That it no longer has an option
to work in the old manner is the design flaw.  Now there is
no "-e" option that works as it did in early bash versions.  It's
that loss of backwards compat that has become the new design
mandate -- to force old scripts and programs to break.

   A whole host of new replacements and improvements to *nix are
moving to replace the old in incompatible ways.  That doesn't
make them improvements, but a move to a new and incompatible
new standard -- the whole thing that POSIX originally meant
to minimize by describing a LCD (Lowest Cmmn. Denom.)
of functionality.