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.

Great solution. Not entirely "side effect free.." On Wed, Dec 16, 2020 at 2:30 PM Richard Salz &lt;rich.salz(a)gmail.com&gt; wrote: