Re: stderr usage instead of /dev/tty

[Padraig Brady]

Paul Jarc wrote:
> Philip Lijnzaad <lijnzaad@ebi.ac.uk> writes:
>
> > Padraig Brady <Padraig@linux.ie> writes:
> >
> > > Nobody commented on my previous patch to bash
> > > to tell it to interact with /dev/tty instead of stderr.
> > > Is it complete lunacy or what? In 10 words or less
> > > why does bash use stderr instead of /dev/tty ?
>
> You want to put bash's output on /dev/tty so you can more easily
> manipulate other programs' stderr, right?

Yep. And also bash's errors. The patch only puts the interactive
stuff (printing of prompt and readline stuff) to /dev/tty.

> But you can already use
> redirections to separate them.  Putting bash's output on /dev/tty
> gives you this separation for free, but it makes it harder (but not
> impossible; see below) to manipulate bash's stderr.  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.
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.

> What happens when someone else comes along and
> says some other random program should use /dev/tty just so they don't
> have do the redirections?  It doesn't scale - when more things start
> going to /dev/tty, we've lost the separation we had initially, and
> we've made it harder to do the separation manually.
>
>
> > you might like to ignore stderr, or to pipe it to some other process
> > or redirect it to a particular file. All of this is not possible
> > with /dev/tty
>
> It is possible - sort of.  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>.  Of
> course, when redirecting the wrapper's stderr, you're redirecting
> /dev/tty for *everything* running under it.  To separate them, you'll
> still have to do redirections for individual commands.

Hmm sounds messy, I'll have a look.

> > which isn't even be available on non-interactive processes like a
> > cron job.
>
> 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.

> paul

Padraig