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

101–110 of 159 posts

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

#101

Post by tzs »

paulddraper wrote: post #31
simcop2387 wrote: post #20

Earlier quoted context omitted.

You can't trap kill can you? doesn't that just go kill your process without any possibility of intervention or other actions? Also you probably want to handle HUP there too I would think (depending on what the script does)

SIGABRT would have to come from the process itself; IDK when if ever the shell would do that. And SIGKILL can't be handled, so that is indeed pointless.

In sufficiently old Unix (I remember doing this on 32V) there was a fun little hack you could do with SIGKILL. If you sent SIGKILL to a process and that process was being debugged it would not kill the process. It would just pause it and notify the debugger that the process had received a signal, and tell the debugger which signal.

The debugger could then allow the signal to go through to the process as is, or to replace it with another signal, or have it be ignored.

I made a program that looked like sh in ps, but actually was a simple debugger that just ran a specific other processes of mine. When that process hit a signal the debugger poked the signal number into a fixed location in the process' memory, then changed the signal to something innocuous like SIGALRM, and let that be delivered.

The process' SIGALRM handler would get the original signal number that the debugger had poked in, and print some obnoxious message like "Stupid sysadmin...your wimpy SIGxxx cannot hurt me!" where xxx was whatever signal someone had tried to send it.

I then told my fellow admins I had a stuck process that I could not kill, and asked them to kill it.

It took quite a while before someone got suspicious enough to suspect that the sh that was the parent of the "stuck" process wasn't actually a normal shell and try killing it.

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

#102

Post by cvalka »

anaganisk wrote: post #9
cvalka wrote: post #8

[flagged]

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.

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

#103

Post by joshSzep »

inimino wrote: post #93
joshSzep wrote: post #74

Earlier quoted context omitted.

Because ain't nobody got time for that. ;) More seriously, I think that we have been trained to rely on just in time searches (or ChatGPT sessions) when we encounter the next thing we need to learn. RTFM is just so time consuming and I personally don't recall everything I have read, leading me to rely on search/AI to re-learn the next thing just in time anyways. In some ways this is a vast improvement, which is why i…

The thing is that reading the manual isn't easy. If it was, everyone would do it, because the benefit is that, eventually, you know every topic or section that appears in the bash man page, and then eventually you know most of what that page says about most of those features. These efforts compound over time. If you reach that point, you know that if you don't know of a feature in that software, it doesn't exist. You…

Excellent comment, inimino.

> Over ten or twenty years, the difference between these two habits is night and day. The people who read the documentation first, and only then ask for help, and the people who ask for help first and get it and so never read the docs, end up in a totally different place with respect to overall confidence and comfort with the tools.

Ooof! This one's hit home.

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

#104

Post by cvalka »

mttjj wrote: post #10
cvalka wrote: post #8

[flagged]

Can you expand on your first sentence with some reasons or justifications for stating this?

For most use cases a guy like him writes a shell script, there's already some well written software. F.e. in his case, he'd used something like Dagu. Don't write shell scripts. If you want to do some programming, pick a proper programming language.

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

#105

Post by chasil »

tzs wrote: post #101
paulddraper wrote: post #31

Earlier quoted context omitted.

SIGABRT would have to come from the process itself; IDK when if ever the shell would do that. And SIGKILL can't be handled, so that is indeed pointless.

In sufficiently old Unix (I remember doing this on 32V) there was a fun little hack you could do with SIGKILL. If you sent SIGKILL to a process and that process was being debugged it would not kill the process. It would just pause it and notify the debugger that the process had received a signal, and tell the debugger which signal. The debugger could then allow the signal to go through to the process as is, or to rep…

That is quite a story!

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

#106

Post by chasil »

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 terminates normally (exits), and may occur when the shell terminates abnormally as a result of delivery of a signal (other than SIGKILL) whose trap action is the default.

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

#108

Post by [deleted] »

ykonstant wrote: post #78
thelastparadise wrote: post #55

Earlier quoted context omitted.

How have exit traps come back to bite you?

# usage : utility NEW_DIRECTORY -- user : I think not # trap 'cleanup' INT HUP TERM cleanup() { rm -rf "${mydir}" ;} # stuff mydir="${HOME}/$1" # but $1 is empty if test -z "$1"; then # handle; but while stuff is happening, # user presses Ctrl-C fi

[deleted]

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

#109

Post by parentheses »

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…

Clearly it's a rhetorical device that may be a bit more heavy handed than one you'd used.

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

#110

Post by dangus »

throwawaaarrgh wrote: post #54

Don't use traps unless you have to. They are subtly complex and require a great deal more code to deal with edge cases. There is almost always a simpler way to accomplish what you want. If Bash has taught me anything, it's that many advanced features should seldom be used. Always resist the temptation to be fancy.

In my mind, as soon as you approach anything remotely resembling "fancy," you should move on to a different language or framework that isn't a bash or shell script at all.

I start questioning whether I should be writing bash as soon as I hit about ten lines. I won't even consider writing functions or loops.

If I'm manipulating the system, I'm probably using configuration management, and for most other tasks, I'm using a full-blown programming language with a nice set of standard libraries.

E.g., Python and Ansible.

Post reply on HN