Keresztfalvi Gabor <[EMAIL PROTECTED]> writes:
> I cleaned up my patches. They can be applied on snapshot-1999-01-28.
> client.c:
Thanks.
> - I moved the termios struct from pty_request to client_session to be able to
> restore the original term settings on exit. (I put the restoring code to
> close_client_session. Maybe there is better place for it.)
> A raw mode flag and a tty file descriptor is also placed into
> the client_session object.
Good. I have considered usning atexit/onexit for things like restoring
the pty mode. One other thing to do, that would be friendly to the
parent shell is to restore blocking mode on the stdio fd:s.
> - Setting the client term to raw mode now happens in do_pty_result. In this
> func I also fill the termios struct and set the raw flag of the
> client_session instance.
Sounds reasonable.
> server.c:
> - The most painful change is that if we have a PTY we _must_ pipe the stderr
> through the PTY! If we don't do this, programs which want to set the
> terminal params, will fail with a message like this: "stderr: invalid
> argument". And also bash will look bad, because the prompt is printed to the
> stderr, and if it goes through a separate channel, the client will display
> it incorrectly on its raw terminal.
I must say that I *really* don't like this change. I want to be able,
for instance, to run an interactive program on the server, while
redirecting stderr to a local log file. And the ssh2 protocol lets me
do things like that.
And I see no reason why bash writes its prompt to stderr rather than
stdout. In the "ordinary" interactive operation, stderr and stdout are
the same (some tty), so it doesn't mattar. But if they aren't, like in
our case, I can't see any reason why sending the prompt anywhere but
stdout makes any sense. Stdin and stdout are where normal interaction
with bash should take place.
But if it is necessary for bash to function properly, I guess we may
have to do it. What's a reasonable way to make it configurable?
/Niels
