True, of course. Without a way to trap from within Mystic or its door process, however, this is the best I could come up with.
Yeah.... Without support in the spawning process, you'll always
have a race. Something you might do is spawn a wrapper (written
in "C" or a similarly low-level language) that sets up signal
handlers and then exec's the real door program. Then, if that
C (or whatever) program takes a signal before the exec, it just
executes the default signal action, which is hopefully harmless
(but not, e.g., invoking a shell or something).
Thanks for the remind about ^\. I'm now trapping SIGINT(2) SIGQUIT(3) SIGTERM(15) and SIGTSTP(20). I think that covers everything a user could do from the keyboard.
Not a problem. A quick grep through tty.c in the kernel
running on my machine shows the driver generating the
following signals:
SIGINT (^C)
SIGQUIT (^\)
SIGINFO (^T)
SIGTSTP (^Z)
SIGHUP (sent to processes on revoke(2) or close())
SIGWINCH (Remote window size change)
SIGTTIN (TTY read from background process)
SIGTTOU (controlling terminal action from background process)
SIGIO (async IO; TTY device ready for IO)
I might have missed one, but this list looks reasonable.
Most are pretty innocuous.
SIGTTOU is kind of interesting; it's when a background
process tries to do something like an ioctl() on the terminal
device to put it into raw mode.
--- Mystic BBS v1.12 A39 2018/04/21 (Windows/32)
* Origin: Black Flag <ACiD Telnet HQ> blackflagbbs.com (21:1/112)