Re: fds beyond 0/1/2

[Simon Tatham <anakin%pobox.com@localhost>]

Nicolas Williams  <Nicolas.Williams%oracle.com@localhost> wrote:
> That's true in the pty case (because the stdout/stderr distinction is
> lost before the writes even happen as the two fildes will both refer to
> the same pty).
> 
> It's not necessarily true in the no-pty case.  If the server uses two
> distinct pipes for stdout and stderr then the relative ordering of
> stdout/stderr writes will be lost.

Indeed, as I said in my next paragraph. But if the server is running
on some entirely different mechanism which does permit distinguished
stdout and stderr data to be transferred from the server-side
application keeping both interleaving and identification, then the
CHANNEL_EXTENDED_DATA system can preserve that as far as the client.

An obvious example of such a server-side application would be one
that's _part_ of the SSH server process and is explicitly
constructing channel data packets! Some dedicated kind of server -
perhaps one running on a router or other embedded-class device -
is easy to imagine doing such a thing, and if it did, it could
extract some actual value from the EXTENDED_DATA mechanism.

But, as I also said, this is irrelevant to the POSIX world and
should be considered an amusing sidetrack only for these purposes.

> Do you really need the multiple fd thing?  Sounds like you might need to
> do some violence to the connection protocol...  Well, maybe not so much
> violence, just a way to link channels.

Yes. I think a basically sensible approach would be to simply
introduce a new class of channel, whose CHANNEL_OPEN message cites
(alongside all the normal stuff) the remote id of a "session"
channel currently in its setup phase, and indicates a file
descriptor (with optional direction) to be opened in the session
channel's process when it's launched. So you'd set up a few of
those, then kick off your shell or subsystem or whatever, and you've
got all the separate windows and EOF statuses you need.

(Perhaps it should also be legal to cite fd 2 in such a message, in
which case the server would never send CHANNEL_EXTENDED_DATA on the
session channel, and stderr would come down the auxiliary channel
instead.)

Cheers,
Simon
-- 
Simon Tatham         "_shin_, n. An ingenious device for
<anakin%pobox.com@localhost>    finding tables and chairs in the dark."