[EMAIL PROTECTED] writes:
> Why do you want to cripple lsh? What rationale do you have for wanting
> stderr to be a pipe instead of a proper pty/tty? You can argue all you like
> about what software should or shouldn't do, but why are you trying to break
> things in the first place?
The short answer is that using the same channel for stderr cripples
the ssh protocol, which I don't want to do, and that programs that
don't handle a non-tty stderr properly seem broken. And in general I
think that it is *highly* relevant what software should or shouldn't
do; I value features useful for programs that behaves right a lot
higher than bug compatibility with broken programs.
But I'll try to do the right thing. That means, that for now I want to
keep the behavoir that stderr is separate channel. If this causes a
lot of problems (if anybody encounters any more problems, beyond the
bash prompting issue that has been mentioned already, I'd like to hear
about them), there are several options:
1. To make the behavior user configurable, in a user's .lsh/config
(this must probably be configured on the server side).
2. To create two pty:s, one for stdin/stdout, and one for stderr. That
solution sounds a little ugly to me.
3. Somehow find out whether or not the client's stderr is a pty or
not, and make sure the processes are started in a similar
environment by the server.
But I think that fancier solutions to this issue can wait until things
like user configuration files exist.
Does that sound reasonable?
/Niels
