Garrett Wollman <woll...@csail.mit.edu> said: | "The shell" is one instance of a programming-language runtime.
Maybe (probably) I wasn't as clear as I should have been, by "the shell" I didn't just mean the thing that POSIX specifies as sh, but any shell like program (even csh) - plus implementations of various "kill" like programs, built into the shell or not (non built-in trap commands are meaningless, so that we can ignore). I fully agree that this would be a useful thing to have available, but to be added to the standard as a new interface being added in 202x it should meet design criteria that are appropriate today - and do only what the interface should do. Making it too shell (generic shell) specific is undesirable, or we end up with nonsense like the described "kill -EXIT pid" by accident, just because no-one thought to explicitly check for that case. If implementing the trap command (rather than kill) or something similar to it, and we need to handle more than just signal names, then those extra names are application dependent, not system dependent - some shells handle not only "exit" as an additional trap, but some or all of "debug" "err" "return" (probably more) as well. The ancient SysVR4 shell didn't, so str2sig() (and sig2str()) don't handle those, but if it had? That is, while knowing what signals exist on a system is not completely trivial -- parsing signal.h - or more often sys/signal.h - for this info isn't usually difficult, but that's not the best thing to do, as it means the application (every application that does this) needs to potentially be rebuilt every time there's a system upgrade, which isn't an ideal solution (the same is true of any use of constants like SIG2STR_MAX and NSIG_MAX of course, which is why they're also a poor idea) -- a way to dynamically determine the signals that exist at runtime, and their names and values, is a much better idea - the proposed interface handles (poorly) the latter two parts, it doesn't allow discovery of what exists however (and passing every integer between 1 and NDIG_MAX-1 through sig2str() to see what returns a name isn't safe, even if it wasn't, as currently proposed, required to return a name for every intervening value, valid signal or not, as NSIG_MAX is permitted to be MAX_INT (so is the result of sysconf(_SC_NSIG)), and 2 billion calls of sig2str() at startup (even if just an outside possibility) is a cost no sane application would allow. [Aside: remember that NSIG_MAX (and sysconf(_SC_NSIG)) is defined as being 1 more than the highest signal number that exists (or might exist) - it has no relationship at all to the number of signals that exist.] That's why, as useful as this interface would be, if properly designed, to a limited set of applications, we're likely to be much better off waiting upon a suitable better designed interface becoming available, and widespread (at least enough that we can be confident it works without major defects) before adding anything to the standard. After all, we have survived with no real complaints about its lack all this time - we can last another decade or so. kre
