Re: stderr usage instead of /dev/tty

[Paul Jarc]

Padraig Brady <Padraig@linux.ie> writes:
> Paul Jarc wrote:
>> What makes bash special, that its output should be automatically
>> separated from other processes' output?
> 
> Nothing really. I think all processes that need to interact with a user
> should use /dev/tty and not stderr. It's much more flexible in my opinion.

It makes it *harder* to redirect the prompt and such.  What would
definitely be more flexible is if bash let you use normal redirection
for interactive stuff independently.  E.g., bash would open fd 3 to
/dev/tty at startup for interactive shells (if fd 3 were already open
to a tty, leave it alone); then bash would send interactive output to
fd 3, and you could redirect it like anything else.

> A simple application of what I was thinking is, you could just
> redirect stderr of bash (and hence it's children) to an output
> colorizer, so you have nice red errors for e.g. This breaks of
> course if applications use stderr for interaction,, but at least
> it's easy to turn off.

Another way to approach this is to have bash let you establish an
intermediate interpreter.  bash reads a complete command; then it runs
your interpreter command with the read command in $BASH_COMMAND or
whatever.  You could do something like:
$ bash-set-interpreter 'eval "$BASH_COMMAND" 2> somewhere'
bash-set-interpreter would be a new builtin.

>> You can have a wrapper program that runs a command in a
>> pseudoterminal; the command's /dev/tty is the wrapper's stderr, and
>> you can redirect the wrapper's stderr.  See the ptybandage program
>> in <URL:http://cr.yp.to/software/ptyget-0.50.tar.gz>.
> 
> Hmm sounds messy, I'll have a look.

Disclaimer: no particular relevance to the problem you're trying to
solve is expressed or implied.  WRT this problem, ptyget may seem
messy, but WRT the problems it's intended to solve, it's quite nice.

>> Right, processes without a controlling terminal can't open /dev/tty.
>> But they can open a terminal device file, which can result in that
>> terminal becoming the controlling terminal.  They'd be able to open
>> /dev/tty after that.
> 
> No need (as stated above) unless the shell is interactive.

I wasn't saying anything needed to do so.  I was just describing what
processes (not necessarily shells) *can* do.


paul