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)

That's what they put on the ticket, so that's what I'm using, but you're probably right.

SIGABRT is also not a normal termination signal. Seems out of place here.

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.

POSIX says that "setting a trap for SIGKILL or SIGSTOP produces undefined results", but for signals it describes SIGKILL as "Kill (cannot be caught or ignored)".

I'm guessing this is some relic from 80s Unix systems where SIGKILL behaved different, or perhaps just an inconsistency/oversight.

I read that as undefined in terms of how the shell itself handles it, because the OS doesn't care.

I think it means that it is valid for OSes to return an error instead of doing nothing, if you attempt it.

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 "stuck" processes parent wasn't actually a normal shell and try killing it.

That is quite a story!

It's like the software equivalent of an Annoyatron! I love it!

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

Harsh lesson, those five signal names are identical if one squints real good. Would have never known.

`man 7 signal` on linux or just `man signal` on macOS will give you more information about the different signals, and shows what the different meanings of those are.

"kill -l" gives you a terse (but complete) list.

I think you want:

  trap 'ssh-agent -k' EXIT INT TERM

I don't see any reason for the eval as "ssh-agent -k" doesn't return anything useful you want the shell to evaluate.

That's not what the eval is for.

The "ssh-agent -k" command will emit shell commands that the shell must then execute which will kill the agent daemon and unset the socket environment variable.

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

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.

If all you care about is killing it, you don't need to eval the output. The output just unsets two environment variables which only matters in the current shell context.

  $ ssh-agent
  SSH_AUTH_SOCK=/var/folders/8p/_pwq997168s7vdwwdg_qr1j40000gn/T//ssh-DE0IoJfU5rrM/agent.15015; export SSH_AUTH_SOCK;
  SSH_AGENT_PID=15016; export SSH_AGENT_PID;
  echo Agent pid 15016;

  $ SSH_AGENT_PID=15016; export SSH_AGENT_PID;
  $ ssh-agent -k
  unset SSH_AUTH_SOCK;
  unset SSH_AGENT_PID;
  echo Agent pid 15016 killed;

That said, it doesn't hurt to eval it, so I overstated my case in my original comment.

The signals EXIT HUP INT TERM cover everything I've run into (I'm actually using EXIT SIGHUP SIGINT SIGTERM but presumably it's equivalent).

In basic terms for my purposes these respectively account for a clean exit, the terminal emulator being closed, ctrl-c, the kill command (edit: the default SIGTERM kill -15, not the SIGKILL kill -9)

What's the signal for SIGKILL?

SIGKILL can't be handled. It's the signal you send when you don't want to give the process a chance to handle it.

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. https://www.youtube.com/watch?v=Fow7iUaKrq4

This is mandatory viewing

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.

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.

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

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

It's a very common mistake with trap.