“Exit traps” can make your Bash scripts more robust and reliable (2013)

how about you?

There's this idea that macOS is "based on BSD", but that's not really the case in any meaningful way; it took some components, but the system overall isn't really "based on it" as such.

    # All normal and error exits

    trap 'e=$?; trap - EXIT; your cleanup here; exit $e' EXIT

    # Error only trap

    trap 'e=$?; trap - ERR; your error only cleanup here; exit $e' ERR

Untrapping is necessary to prevent multiple calls, especially if it can call exit or fail within the trap handler.

You don't need an exhaustive list of signals, which is almost never correct in oft touted cargo culted examples.

I agree, shell programming is ugly and very unsafe.

> Anything more complex than that? Python, Perl, or any other proper programming language is there for you.

I disagree.

First, there are certain things, specifically when you want to process very large datasets that are easiest - by a very large margin - to build using shell scripts: a combination a ripgrep, sed, awk, grep, cut, tr, paste, jq, head, tail, etc ... is way easier and faster to put together in bash than anything else.

Second, to get maximum flexibility you'd like to be able to switch from one (python, perl) to the other (shell script) transparently and both ways

Do certain things that can be expressed cleanly in python, and then transparently switch to bash calling a horde of specialized shell commands when the task at hand is easier to express that way.

Shell can transparently go down to Python or Perl very, very easily.

Unfortunately, the converse is absolutely not true: while Perl can - to a certain extent - be used to construct complex pipelines of data processing external commands, it is nowhere near Shell in ease of use.

And it is a giant PITA in Python which gives you fuck-all above exec/fork level subprocess manipulation: writing large external pipelines in Python is about as easy as it is in C.

Regarding the expected behaviour: I believe this is largely a matter of preference/philosophy. I have previously used trap handlers in bash scripts explicitly so that the cleanup is run in every case and /tmp is not polluted - even of failures. Reasoning: For automated tasks or people not familiar with Linux/my script, the disk should not be filled up with old garbage data. And for debugging, I usually add a '-d/--debug' option to have more verbose output and disable the cleanup on Ctrl+C (but still cleanup on normal exit).

But as I said, I don't believe there is the one true way. So except for pointing out that I had to ensure external cleanup in case the script was run by some auomated tasks in a permanent environment (read: native), I wouldn't seriously complain if I ever used one of your scripts :)