>>>>> "Niels" == Niels =?ISO-8859-1?Q?M=F6ller?= <[EMAIL PROTECTED]> writes:
Niels> Carson Gaspar <[EMAIL PROTECTED]> writes:
>> stderr _must_ be processed the same way stdin is. If you don't want them
>> to share a pty, you need to allocate 2 (which is what the kerberos stuff
>> does, as I recall).
Niels> This statement does not make much sense to me. The things you can do
Niels> on stdin (input) and stderr (output) are quite different. Even the
Niels> ttyflags for input and output are mostly orthogonal.
Whoops - brain-o. I meant stdout and stderr. I shouldn't post when I'm sleep
deprived :)
Niels> On a more practical side, what problems can I expect if stdin and
Niels> stdout are a pty but stderr is not? Bash appearantly writes its
Niels> prompts to stderr (as is demostrated by running bash -i >/dev/null;
Niels> the prompt still appears). Unless I'm told some very strong reasons
Niels> for that, I consider it a bash bug, even if it may be a bug we have to
Niels> live with. Are there any other programs we can expect problems with?
Niels> How do other interactive shells behave, for example?
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.
On the other hand, stderr _must_ have the same tty properties as stdout by
default. If we don't make them the same pty/tty pair, we have to do the same
terminal voodoo to both. bash _does_ require this, and not incorrectly.
--
Carson Gaspar -- [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
http://www.cs.columbia.edu/~carson/home.html
Queen Trapped in a Butch Body
