[EMAIL PROTECTED] writes:
> Stdout and stderr do _not_ need to be the same thing. Any piece of software
> that assumes they are is broken. bash doesn't assume that they're the same -
> it just uses both. As a counter-example, "bash -i >/tmp/foo" allows you to
> execute commands and have the output go to /tmp/foo, but still see what
> you're typing.
Thanks, that is a valid example.
But I don't think I want to give up this point just yet. I think bash
could be fixed to send its prompt to stdout or /dev/tty rather than
stderr. And in any case, if it is a problem that lshd uses a simple
pipe for stderr, one can always work-around that with
exec 2>/dev/tty
in bash. I'm sure someone more fluent in shell programming than me can
come up with something to redirect stderr onto stdout or /dev/tty iff
stdout is a tty but stderr isn't.
/Niels
