From the signal() manual page:
When a process which has installed signal handlers forks, the child pro-
cess inherits the signals. All caught signals may be reset to their de-
fault action by a call to the execve(2) function; ignored signals remain
ignored.
So I would say that it is definitely ssh that is changing the SIGPIPE
methodology. gunzip must be exiting without generating an error message
with SIGPIPE is SIG_DFL. If gunzip were ever to catch the signal and
report it, though, we will wind up with the errors popping up again,
even if we fix ssh. For now I think ssh should be fixed.
-Matt
:On Sunday, February 11, 2001 03:41:48 -0500, Barney Wolff
:<[EMAIL PROTECTED]> wrote:
:+-----
:| Er, could it possibly be that telnet has been hiding the error
:| all along? It's really, really hard to see how ssh could
:| *create* this sort of error.
:+--->8
:
:Someone mentioned earlier that sshd seemed to be setting SIGPIPE to SIG_IGN
:in the child shell; that would lead to subprocesses getting EPIPE instead
:of SIGPIPE, and typically the application reports the former and tar's
:parent the latter, so the new error behavior would be expected.
:
:--
:brandon s. allbery [os/2][linux][solaris][japh] [EMAIL PROTECTED]
:system administrator [WAY too many hats] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
