"Tomas Fasth" <[EMAIL PROTECTED]> writes:
> Besides, using POSIX names for passing information about *nix signals from
> one implementation to another seem to be a fairly good compromise. If one
> system uses proprietary signals which is "unknown" by others, it's not very
> useful to know it's machine representation anyway. And even if it would be a
> machine to machine thing, they have had to agree on a common ground. POSIX
> is one such.
Perhaps you're right. But using names instead of numbers requires a
change of the protocol, not just a clarification.
> But it might also indicate that this is a non-issue, that is, no one really
> care because it does not break anything.
Perhaps nobody uses signals. But I can imagine uses for signal
forwarding. Say that you want run a remote program, that does certain
things when signaled. Then you could request that your ssh-client
forwards, say, SIGINT or SIGHUP; when you signal the client process,
it delivers the signal to the remote process. This would naturally be
most useful for deamon-like programs which don't offer any command
line or other user interface. Even if I admit that remote deamons
sounds a little bizarre.
For the other direction (the exit-signal message), I think I agree
that you probably don't want to use the signal for anything but user
notification. It sounds like a bad idea to have the client SIGSEGV:ing
itself (for instance) just because the remote process was killed by
that signal.
/Niels
