Just use Python or any other proper high-level language that has proper control structures.
“Exit traps” can make your Bash scripts more robust and reliable (2013)
61–70 of 159 posts
Re: “Exit traps” can make your Bash scripts more robust and reliable (2013)
#62An annoying thing about bash is that EXIT will also run on SIGINT (^C), which most other shells won't (in my reading it's also not POSIX compliant, although the document is a bit vague). Some might argue this is a feature, but IMHO it's a bug – sometimes you really don't want cleanup to happen so people can inspect the contents of temporary files for debugging. Because trap doesn't pass the signal information to the…
if you're debugging hit ctrl+z and it will suspend the script in place
Re: “Exit traps” can make your Bash scripts more robust and reliable (2013)
#63> and may have security implications too
While it's certainly true that leaving around files with sensitive data is a security problem, you probably don't want to put sensitive data in /tmp to begin with.
Re: “Exit traps” can make your Bash scripts more robust and reliable (2013)
#64> and may have security implications too While it's certainly true that leaving around files with sensitive data is a security problem, you probably don't want to put sensitive data in /tmp to begin with.
Why not?
Re: “Exit traps” can make your Bash scripts more robust and reliable (2013)
#65>The secret sauce is a pseudo-signal provided by bash, called EXIT, that you can trap; commands or functions trapped on it will execute when the script exits for any reason. "Secret Sauce", why is this secret at all. Nothing against the author who's helping the ecosystem here, but is there an authoritative guide on Bash that anyone can recommend? Hopefully something that's portable between Mac & Linux. The web is ful…
It's secret enough to be well documented in the man page. The real question is, why do people look to random web pages prior to having digested everything in the manual? People used to say "rtfm" all the time, this would be regarded as shockingly rude in today's tech culture but it was a valuable public service to have it repeated, like being reminded to eat your vegetables.
Re: “Exit traps” can make your Bash scripts more robust and reliable (2013)
#66Should go without saying, but don't rely on this for anything critical. It's not guaranteed this will run, even on successful completion of the script. Simple example: power is cut between the last line of the script and before the trap runs. Just a heads up
If you were building a critical system, what would do if power is cut after the last line of a script runs?
Idempotency is usually the best approach - have each step of a process examine the state of the disk and act only if it's an appropriate input then output something that isn't an appropriate input. Assuming you can ignore midstream corruption (which can safely be done by adding an atomically safe linking layer on top) then if power suddenly cuts out reboot and run the script until a clause finds an appropriate input and executes it continuing from there.
The concepts are simple, the implementation is a pain and (honestly) if you need something truly resilient you're probably better off leaning on a system that can provide that guarantee for you (like using a database for state storage).
Re: “Exit traps” can make your Bash scripts more robust and reliable (2013)
#67> and may have security implications too While it's certainly true that leaving around files with sensitive data is a security problem, you probably don't want to put sensitive data in /tmp to begin with.
Why not?
The program could get paused mid-execution. Moreover, I’m pretty sure a malicious process can put file watchers in /tmp and read all written contents.
Re: “Exit traps” can make your Bash scripts more robust and reliable (2013)
#68Earlier quoted context omitted.
How have exit traps come back to bite you?
The first is that the trap can come at any time. You can't assume at what point in the script it was running, so you have to test for different cases to find out what you now can/should do. Forget an edge case and now you've got an extra bug. Not using traps, it's clearer what happens at specific points in the execution of the rest of the code, so simpler to reason about how to deal with those cases as/where they hap…
As with most things in programming, it sounds like if you use the wrong tool for the wrong job, then you're prone to writing bugs. Using traps is a great idea when used properly and dismissing it outright isn't doing anyone any favors.
Re: “Exit traps” can make your Bash scripts more robust and reliable (2013)
#69Just use Python or any other proper high-level language that has proper control structures.
Sometimes you can “just use python”, like openwrt script or similar.
Re: “Exit traps” can make your Bash scripts more robust and reliable (2013)
#70>The secret sauce is a pseudo-signal provided by bash, called EXIT, that you can trap; commands or functions trapped on it will execute when the script exits for any reason. "Secret Sauce", why is this secret at all. Nothing against the author who's helping the ecosystem here, but is there an authoritative guide on Bash that anyone can recommend? Hopefully something that's portable between Mac & Linux. The web is ful…
It's secret enough to be well documented in the man page. The real question is, why do people look to random web pages prior to having digested everything in the manual? People used to say "rtfm" all the time, this would be regarded as shockingly rude in today's tech culture but it was a valuable public service to have it repeated, like being reminded to eat your vegetables.
Possibly? At this point there are a lot of manuals out there and it's unreasonable to try and read them all. Developers work with a plethora of tools and I think modern tools are getting better at not being surprising but some of these old tools have design choices that differ from modern habits.
I think this might be a bit easier to appreciate if you've ever worked at a young company and made choices because you have to (oh, we'll use MySQL, that sounds better than Postgres) and then give yourself an extra three months work in two years when you finally come up against a shortcoming in the tech. We have to make an awful lot of decisions and generally don't have the budget in time or money to fully grok the options we're deciding between.