Re: [TUHS] sh and goto

[George Michaelson <ggm@algebras.org>]

HN has a story about a safe bash script template. Putting to one side
the oxymoronic qualities of the sentence, the thing which stands out
is the use of trap to a function on SIG<x> -Which we all need, but
often don't do. Thumping ^C repeatedly when things go unexpectedly
wrong, is a fact of life. What do you want your script to do?

Coding for the unexpected is just hard. Going into a script (or
program) pre-thinking that you have to 'expect the unexpected' breaks
the design imperative of planning for success. IF-THEN-ELSE doesn't
always cope well with mental models of "do A,B,C but if Z happens get
2 dozen milk" (which leads to the joke about programmers shopping
instructions with an IF clause in it)

The trap thing in shell always confused me. What state am I "in" when
I wind up in that trap? do variables exist (no: IIRC the var=value
flow in a shellscript is lazy so the un-instantiated x=y inside an if
expression you don't know was reached or not MAY not exist)  has
sub-job completed, (can trap pre-empt a wait statement? of course it
can! what does it mean for children reaping... you do know the PID
right?)

None of this is rocket surgery. It goes to lawyer-like legalistic "one
side of one cow in one field is black" reasoning -which for a program
is probably not a bad thing, but it isn't very human(e) thinking for
some people.

Then enters ^T (the TOPS-10 inherited "what state am I in, in terms of
CPU time and I/O") which somebody *else* is dealing with: the thing
which called your shell instance..

trap is a setjmp/longjmp type outcome. You pop up in a call you didn't
exactly "plan" for (well you did: you wrote it. But you don't know the
entry state which led you there, unlike normal program flow) -well, it
is.. because you get there. But you aren't going back to your normal
logic flow anytime soon in any shellscript I saw.