bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stderr usage instead of /dev/tty


From: Paul Jarc
Subject: Re: stderr usage instead of /dev/tty
Date: Wed, 08 Aug 2001 11:24:12 -0400
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7

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?  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?  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.

> 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.


paul



reply via email to

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