develooper Front page | perl.perl5.porters | Postings from October 2003

Re: [perl #24204] Dupping STDERR for reading.

Thread Previous | Thread Next
Mark Jason Dominus
October 22, 2003 04:27
Re: [perl #24204] Dupping STDERR for reading.
Message ID:
Matt Sergeant <>:
> On 17 Oct 2003, at 17:11, Mark Jason Dominus wrote:
> > I spent a large chunk of yesterday combing over POSIX to see what it
> > says about this, and my conclusion is that POSIX requires that it be
> > possible to open STDERR for reading.  (!!)
> I'm not sure if this is the same bug or not, but sometimes under perl 
> 5.8 re-opening STDERR on another filehandle fails (I've been unable to 
> pin down exactly why, as I found a work-around).
> This (mis)feature is used extensively by qmail, and by extension is 
> also used by qpsmtpd. I recently had to patch qpsmtpd I assume because 
> of this change. (I switched to using POSIX::dup2() instead of open()).

[Caution: My message has very little to do with yours.]

It's perfectly ordinary to reopen STDERR onto another filehandle and
then to write error messages to the filehandle.  What's weird is to
open STDERR for *reading*.  I'm pretty sure that qmail doesn't do
that, because one of the things I found while I was researching the
matter was a software package written by Daniel J. Bernstein (author
of qmail) which includes the following:

        .I e
        Do not guarantee readability of stderr to the pseudo-terminal.
        This should be default, but such programs as
        .I csh
        .I more
        insist on reading from stderr and dying horribly
        if they fail,
        even though half a teaspoon of common sense indicates
        that the
        .B standard error
        is actually meant for printing
        .B errors.


I agree with Dan here.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About