[Top][All Lists]

[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: Thu, 09 Aug 2001 16:32:12 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801

Paul Jarc wrote:
Philip Lijnzaad <address@hidden> writes:

Padraig Brady <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]