Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

redsymbol.net

Post reply on HN
Print view View original

151–159 of 159 posts

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

#151

Post by npongratz »

usr1106 wrote: post #141
tjoff wrote: post #115

Earlier quoted context omitted.

> For robust code you should also use set -e. Highly debatable.

What are the arguments to leave it out? Of course in special cases where you do explicit error handling you can disable it. But for the big mass of commands where nobody checks whether it worked.

http://mywiki.wooledge.org/BashFAQ/105#So-called_strict_mode

> The behavior of set -e is quite unpredictable. If you choose to use it, you will have to be hyper-aware of all the false positives that can cause it to trigger, and work around them by "marking" every line that's allowed to fail with something like ||true.

Start there, then go back to the beginning for the extensive exposition against using set -e.

FWIW, I (a random person on the internet) use set -e for most scripts I write, and despite the caveats, find set -e is generally more beneficial than troublesome. I don't think Mr. Wooledge is wrong, it's just the groove I've settled in. I do sometimes consciously avoid using set -e, when I explicitly handle errors for every single element of the script.

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

#152

Post by usr1106 »

npongratz wrote: post #151
usr1106 wrote: post #141

Earlier quoted context omitted.

What are the arguments to leave it out? Of course in special cases where you do explicit error handling you can disable it. But for the big mass of commands where nobody checks whether it worked.

http://mywiki.wooledge.org/BashFAQ/105#So-called_strict_mode > The behavior of set -e is quite unpredictable. If you choose to use it, you will have to be hyper-aware of all the false positives that can cause it to trigger, and work around them by "marking" every line that's allowed to fail with something like ||true. Start there, then go back to the beginning for the extensive exposition against using set -e. FWIW,…

The link is interesting, but more a rant than convincing not to use set -e. What would be the alternative? Handling errors yourself in every single command will for sure introduce more surprises and bugs. Of course bash is not the language to control a nuclear power plant. Even C has tons of undefined behavior. But writing all the shell scripts we use in this company without major problems in Rust would be prohibitively expensive.

I do not doubt that may bash scripters shoot themselves in the foot. You need at least one reviewer that understands well how the language works.

That said I prefer dash for scripting except when I really need arrays, which is rare. I have no scientific evidence, but KISS is good and bash just seems to have too many bells and whistles. And as the article mentions, bash seems to change in surprising ways between versions. I have also been bitten by that. Unfortunately dash has no set -o pipefail.

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

#153

Post by dredmorbius »

vbezhenar wrote: post #64
michaelmior wrote: post #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.

Why not?

It's possible to gather some information from a directory to which an attacker has write access, though I'd have to look up details.

In general, this can usually be mitigated to some extent by creating a directory to which only the owner has access.

There are a number of ... interesting ... other circumstances which you might want to consider:

- /tmp is mounted as a ramdisk / memory-only filesystem. This is guaranteed not to persist over reboots, though there may be residual artefacts in memory even after a power-off. That last isn't a significant concern for many people, though it may turn up for others.

- /tmp is a network share. This is uncommon, but NFS + sudo across shared systems means that a user on a remote system may be able to assume your credentials and access or modify your data. rootsquash means that root isn't available, but sudo means that any UID can be defined.

- Various filesystem permissions or limitations may or may not apply to /tmp. I tend to prefer mounting /tmp as its own filesystem, with nodev and nosuid set. There might also be noexec, which can foul up a lot of temporary installation scripts.

An alternative is for users to define their own preferred temporary directory. I usually include ~/tmp under $HOME.

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

#154

Post by cabalamat »

AHOHA wrote: post #69
cabalamat wrote: post #61

Just 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.

According to the openwrt website[1], packages exist for Erlang, Lua, node.js, Perl, PHP8, Python Ruby and Tcl.

[1]: https://openwrt.org/packages/index/start

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

#156

Post by patrakov »

inimino wrote: post #65
filereaper wrote: post #38

>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.

> The real question is, why do people look to random web pages prior to having digested everything in the manual?

Easy! It is a reference manual. It documents every feature, even those that you should not use, does not discuss pitfalls, and does not discuss the best practice. Even worse, there is sometimes a disagreement whether using a particular feature is a good practice. Often there is a factor of adjusting your code style to something that is not too advanced for other people to review.

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

#157

Post by anaganisk »

cvalka wrote: post #102
anaganisk wrote: post #9

Earlier quoted context omitted.

A good read before dismissing http://n-gate.com/software/2017/

Some of his arguments are wrong, some are not even wrong, some are absurd. Plus he seems to be an asshole. Being an asshole and wrong at the same time is not a great combination.

I think you would be very interested to read their takes on HN articles and Fossdem :p

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

#158

Post by inimino »

patrakov wrote: post #156
inimino wrote: post #65

Earlier quoted context omitted.

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.

> The real question is, why do people look to random web pages prior to having digested everything in the manual? Easy! It is a reference manual. It documents every feature, even those that you should not use, does not discuss pitfalls, and does not discuss the best practice. Even worse, there is sometimes a disagreement whether using a particular feature is a good practice. Often there is a factor of adjusting your…

The funny thing about this comment is that man pages do all of the things you mention.

There seems to be a common sentiment that cargo culting random opinions from the internet is a "best practice" and that no code reviewer should ever have to learn anything new during the process. Both of these opinions are in my experience a fast track to a culture of mediocrity.

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

#159

Post by jdiff »

abwizz wrote: post #123
underdeserver wrote: post #121

Earlier quoted context omitted.

+1. Bash is riddled with absurd footguns. You want to set hack together three git commands and pipe to fzf? Fine. Anything more complex than that? Python, Perl, or any other proper programming language is there for you.

i'd argue that every language is somewhat imperfect, but there is something to be said in favor of pitfalls/footguns/inperfections that are somewhat well defined and understood for more than a decade.

A footgun doesn't stop being a footgun with time. New generations of programmers and shell scripters are constantly rolling through and shooting their toes off. Just because there was a "well, that sucks, but it's the least worst compromise" 4 decades ago doesn't make it a good reason today, doesn't make it intuitive today, and doesn't make it not still a horrible footgun today. A familiar footgun is still a footgun.
Post reply on HN