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

141–150 of 159 posts

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

#141

Post by usr1106 »

tjoff wrote: post #115
usr1106 wrote: post #100

Earlier quoted context omitted.

For robust code you should also use set -e. This changes things again. Often a process started by the shell will get the signal, too (depends of course on how it is sent) and exit with a non-zero return value (depends on the process of course). I believe (not at the computer right now) the handler for EXIT is called in that case. Was it so that bash can also trap ERR, but dash cannot? It's not perfectly easy to handl…

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

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

#142

Post by usr1106 »

digitalsushi wrote: post #138
tjoff wrote: post #115

Earlier quoted context omitted.

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

In my enterprise environment of legacy systems with 97% reliability, our scripts often run without -e and the effect is we deliver broken stuff constantly. But people get results. They get an email that says "an unknown error occurred". This can be superior to running some tiny shell script with -e and breaking that communication. It's kind of subjective to the experience.

Of course using set -e without an exit handler is contraproductive.

We use an exit handler that reports

   "$0 has exited prematurely"
in cases the script did not reach expected exit points.

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

#143

Post by usr1106 »

chasil wrote: post #106
chasil wrote: post #11

I used an exit trap to kill an SSH agent that I am running, and I noticed that dash did not kill if the script was interrupted, but only if it ran to successful completion. I asked on the mailing list if this was expected behavior, and it turns out that POSIX only requires EXIT to run on a clean shutdown; to catch interruptions, add more signals. trap 'eval $(ssh-agent -k)' EXIT INT ABRT KILL TERM

I found my original submission to the email list. https://www.spinics.net/lists/dash/msg02208.html "Signal terminations are not caught by EXIT. It only catches normal exits. Unfortunately, the EXIT condition is not well-defined by POSIX, so it's left to interpretation." ... POSIX is making it unspecified what happens here: https://austingroupbugs.net/view.php?id=621 The EXIT condition shall occur when the shell termi…

Why do people write such standards? May occur. I don't need a standard to do something random.

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

#144

Post by usr1106 »

usr1106 wrote: post #143
chasil wrote: post #106

Earlier quoted context omitted.

I found my original submission to the email list. https://www.spinics.net/lists/dash/msg02208.html "Signal terminations are not caught by EXIT. It only catches normal exits. Unfortunately, the EXIT condition is not well-defined by POSIX, so it's left to interpretation." ... POSIX is making it unspecified what happens here: https://austingroupbugs.net/view.php?id=621 The EXIT condition shall occur when the shell termi…

Why do people write such standards? May occur. I don't need a standard to do something random.

I guess to get a well-defined behavior the interrupt handler needs to clear the EXIT trap.

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

#145

Post by jwilk »

chasil wrote: post #11

I used an exit trap to kill an SSH agent that I am running, and I noticed that dash did not kill if the script was interrupted, but only if it ran to successful completion. I asked on the mailing list if this was expected behavior, and it turns out that POSIX only requires EXIT to run on a clean shutdown; to catch interruptions, add more signals. trap 'eval $(ssh-agent -k)' EXIT INT ABRT KILL TERM

And now your script doesn't exit when you ^C it.

It's a very common mistake with trap.

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

#146

Post by 0xbadcafebee »

ur-whale wrote: post #128
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.

> Bash is riddled with absurd footguns 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…

  > > Bash is riddled with absurd footguns
  > I agree, shell programming is ugly and very unsafe.
Sharp knives are "unsafe". Kids shouldn't use them. Professionals prefer them.

I find most 'footguns' to be normal expected behavior, and the user shot themselves in the foot because they're careless or ignorant.

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

#147

Post by shepherdjerred »

w-ll wrote: post #95
moehm wrote: post #94

Earlier quoted context omitted.

That's the difference between kill -15 (SIGTERM) and kill -9 (SIGKILL), where SIGTERM shuts down a process gracefully.

Relevant: Monzy performs at Stanford Univ. "Kill Dash Nine" https://www.youtube.com/watch?v=Fow7iUaKrq4

This is mandatory viewing

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

#148

Post by bencahill »

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…

> is there an authoritative guide on Bash that anyone can recommend?

This guide is a great introduction and I refer back to it from time to time even after using Bash for ~15 years:

https://mywiki.wooledge.org/BashGuide/

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

#149

Post by rigelina »

usr1106 wrote: post #143
chasil wrote: post #106

Earlier quoted context omitted.

I found my original submission to the email list. https://www.spinics.net/lists/dash/msg02208.html "Signal terminations are not caught by EXIT. It only catches normal exits. Unfortunately, the EXIT condition is not well-defined by POSIX, so it's left to interpretation." ... POSIX is making it unspecified what happens here: https://austingroupbugs.net/view.php?id=621 The EXIT condition shall occur when the shell termi…

Why do people write such standards? May occur. I don't need a standard to do something random.

In this type of scenario, it's sometimes because there are two or more implementors that are trying to develop the standard in a way that makes their existing implementation compliant. Likely there were existing scripts that relied on the behavior being specific to that implementation, so it was explicitly made optional, which is viewed as better than not adding the behavior to the standard at all. "May" is just a polite standards way of saying "Warning: check yourself before you wreck yourself."

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

#150

Post by BossingAround »

0xbadcafebee wrote: post #146
ur-whale wrote: post #128

Earlier quoted context omitted.

> Bash is riddled with absurd footguns 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…

> > Bash is riddled with absurd footguns > I agree, shell programming is ugly and very unsafe. Sharp knives are "unsafe". Kids shouldn't use them. Professionals prefer them. I find most 'footguns' to be normal expected behavior, and the user shot themselves in the foot because they're careless or ignorant.

There's a difference between using a sharp knife, and a hammer that has been sharpened on one side so that it's usable as a knife, and pointy on another side so that it can be used as a weapon in case of a home intrusion, while keeping one side as an actual hammer and the handle is covered in honey for more friction in case your hands get sweaty.

Both can be unsafe, but one is a professional tool while the other is an abomination for our current standards.

Post reply on HN