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

81–90 of 159 posts

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

#81

Post by pmarreck »

chasil wrote: post #49
leodag wrote: post #44

Earlier quoted context omitted.

> The "ssh-agent -k" command will emit shell commands Does it really? I've executed it here and it just runs kill, doesn't emit any bash. Running just ssh-agent (without any args) does that though, which is what's probably causing the confusion.

I am on OpenBSD 7.2, and I see: $ eval $(ssh-agent) Agent pid 56785 $ ssh-agent -k unset SSH_AUTH_SOCK; unset SSH_AGENT_PID; echo Agent pid 56785 killed; The correct processing of that output requires an eval. Did you have any other questions?

Why do you need to eval it?

$(ssh-agent)

won’t substitute that with the stdout and run that?

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

#82

Post by pmarreck »

ggm wrote: post #25
arp242 wrote: post #7

An 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…

Some temporary file remover. Lol indeed

The nice thing about temp files is that the OS will eventually remove them, even if you don't

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

#83

Post by tyingq »

simcop2387 wrote: post #20
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

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)

You can't, though probably common for a parent to spin off a child and handle the SIGKILLed child via waitpid().

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

#84

Post by collinvandyck76 »

I like this but the lazy part of me just treats anything i write into $(mktemp -d) as something that will be eventually GC'd by the operating system. I have no idea when it actually happens, or if it does at all, but that's how i roll.

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

#85

Post by abathur »

e12e wrote: post #50
abathur wrote: post #15

I like combining this with a bash implementation of an event API ( https://github.com/bashup/events ). This makes it easy/idiomatic, for example, to conditionally add cleanup as you go. Glossing over some complexity, but roughly: add_cleanup(){ event on cleanup "$@" } trap "event emit 'cleanup'" HUP EXIT start_postgres(){ add_cleanup stop_postgres # actually start pg } start_apache(){ add_cleanup stop_apache # actual…

Thank you for sharing - if i understand the code, the queue is serialized into bash variable(s) (arrays)? I must admit I find the code somewhat painfully terse and hard to read. Still, interesting idea. I wonder if using a temporary SQLite/Berkeley DB/etc for queue might generalize the idea to a "Unix" event system - allowing other programs and scripts to use it for coordinating? (Like logger(1) does for logging)?

Yep. Definitely something you can do manually, but the API makes it easier to reason about and coordinate across otherwise disconnected/unrelated code.

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

#86

Post by abathur »

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.

As an aside, I love fat manuals (and change/release notes) that have a bit of interesting arcana tucked away in one or two calm sentences here and there.

Not that I regularly read them all myself, but it's nice to be rewarded with a new dark art (like alias-based ~metaprogramming) every once in a while.

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

#87

Post by chasil »

pmarreck wrote: post #81
chasil wrote: post #49

Earlier quoted context omitted.

I am on OpenBSD 7.2, and I see: $ eval $(ssh-agent) Agent pid 56785 $ ssh-agent -k unset SSH_AUTH_SOCK; unset SSH_AGENT_PID; echo Agent pid 56785 killed; The correct processing of that output requires an eval. Did you have any other questions?

Why do you need to eval it? $(ssh-agent) won’t substitute that with the stdout and run that?

Because the intended use for "ssh-agent -k" is for eval.

While redirecting to /dev/null will certainly work, the agent is holding sensitive credentials (by design), and confirmation of shutdown has a tangible security benefit.

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

#88

Post by e12e »

abathur wrote: post #85
e12e wrote: post #50

Earlier quoted context omitted.

Thank you for sharing - if i understand the code, the queue is serialized into bash variable(s) (arrays)? I must admit I find the code somewhat painfully terse and hard to read. Still, interesting idea. I wonder if using a temporary SQLite/Berkeley DB/etc for queue might generalize the idea to a "Unix" event system - allowing other programs and scripts to use it for coordinating? (Like logger(1) does for logging)?

Yep. Definitely something you can do manually, but the API makes it easier to reason about and coordinate across otherwise disconnected/unrelated code.

Was thinking more as a "global" queue (like how psql/libpq will go look for a socket to local postgres in "the right place") - and a binary/program "event" could "magically" store ("on") and process ("emit") events in a db file /tmp/event..sqlite3 - creating/initializing or re-using db file as needed...

So keep the api, but support cross process queues, more or less.

Post reply on HN