[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: stderr usage instead of /dev/tty
From: |
Padraig Brady |
Subject: |
Re: stderr usage instead of /dev/tty |
Date: |
Fri, 10 Aug 2001 18:52:37 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 |
Paul Jarc wrote:
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.
Yes, it would be more flexible, but is there any reason you would
every need to redirect the prompt/readline() stuff. This is only human
parseable?
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.
Hmm cheers.
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
Cheers,
Padraig.
Re: stderr usage instead of /dev/tty, Padraig Brady, 2001/08/09