Signal-related nitpicks

[jpco]

This issue lists a number of small behavioral nitpicks around signals.

1. Every other shell, when placed in the spot of $sh here, seems to handle the following gracefully, but not es. We should consider some kind of special SIGCHLD handling on startup.

local (signals = $signals -sigchld) $sh -c ls

2. Consider supporting real-time signals on systems that support them (rc does this!)

3. In the taxonomy of https://www.cons.org/cracauer/sigint.html, es is a "WUE" shell, but the ideal behavior seems to be being a "WCE" shell. We should look into this.

4. Possibly related to the above, we should look closer at sigint_newline to see if we can get it "just right" like bash, zsh, and ksh seem to have (judging by whether this command produces exactly one newline after the ^C when sigint is sent in the terminal during the sleep):

bash -c 'bash -c ''sleep 2'''

[jpco]

I have dug up more potential nitpicks in es' signal code.

1. SA_INTERRUPT is obsolescent, unspecified, and it looks like rc gave up on its use back in 2002.
2. Why do we have fallback #defines for SA_NOCLDSTOP and SA_NOCLDWAIT when we don't use them at all?
3. We have some special handling for SIGCLD in setsignal, but not SIGCHLD. This should be mostly fine (it would be crazy if they had different signal numbers), but #ifdef SIGCLD may be false on systems where we want to manage SIGCHLD. (As an aside, do we handle aliases like sigio/sigpoll and sigcld/sigchld well?)
4. I just noticed our special handling for SIGCLD only happens if we don't HAVE_SIGACTION. Presumably a bug, rather than handling some unique behavior of signal() and SIGCLD? Does this logic imply that we don't want to be able to generate sigcld exceptions at all? (Rc yells at you if you try to trap SIGCHLD, but bash happily does it for you. We should probably err on the side of permissiveness, perhaps only disallowing SIG_IGN.)
5. Rc moved their "unconditional exit in child processes" logic from catcher() to sigchk(). That does seem more sane.
6. We really should change the status & 0xff check in forkexec() to WIFSIGNALED(status) -- I missed that earlier.

[jpco]

Looking at the commit history explains why SIGCLD only has special handling with !HAVE_SIGACTION. See these two defines in the config.h from 0.82:

SPECIAL_SIGCLD: true if SIGCLD has System V semantics. this is true at least for silicon graphics machines running Irix. (according to Byron, ``if you trap SIGCLD on System V machines, weird things happen.'')

USE_SIGACTION: turn this on if your system understands the POSIX.1 sigaction(2) call. it's probably better to use this version if you have it. if sigaction() is used, es assumes that signals have POSIX semantics, so the SPECIAL_SIGCLD and SYSV_SIGNALS options are turned off.

So that's interesting; SIGCHLD's special handling isn't something to try to maintain sanity within shell semantics, it's a workaround for old System V behavior around SIGCLD. You can see a similar journey in the commit history in rc: this was a workaround for SysV signals, then the SysV check was eventually removed and this just became the state of things.

I'd like to keep the ability to manage SIGCHLD to at least some degree. The problem, though, is that the shell needs to manage Proc *s, and actually SIG_IGNing SIGCHLD ruins its ability to know when procs should be freed. So we might do something similar to how es handles the environment: lie to the user, and "correct" the state before execing a binary.

While we're thinking about signals, we might also consider adding support for real-time signals like rc does: rakitzis/rc@7248fd4