IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: closing a channel



Markus Friedl <markus%openbsd.org@localhost> writes:

> On Fri, Mar 22, 2002 at 10:30:52PM +0100, Niels Mller wrote:
> >   /bin/sh -c "echo foo; exec >/dev/null; exec 2>/dev/null; sleep 30; exit 17"
> 
> the reason for linking CHANNEL_EOF to CHANNEL_DATA only was:
> 
> /bin/sh -c "echo foo; exec >/dev/null; sleep 30; exec 2>/dev/null; sleep 30; exit 17"
> 
> so the EOF messages triggers a close(stdout) in the client
> without waiting 30 more seconds.

I see. I don't think it's a very strong argument, though. If you
interchange stdout and stderr,

  /bin/sh -c "echo foo; exec 2>/dev/null; sleep 30; exec >/dev/null; sleep 30; exit 17"

you don't get the client to close stderr immediately when the remote
process closes it's stderr.

I'd prefer that sending neither DATA nor EXTENDED_DATA be allowed
after you've sent EOF.

It's still fine to send EOF immediately when you detect EOF on the
process' stdout, but if you do that, you should also stop reading
stderr, or discard any data you get from it. Don't send it to the
client.

/Niels



Home | Main Index | Thread Index | Old Index