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

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

Thread Previous | Thread Next
From:
Mark Jason Dominus
Date:
October 17, 2003 09:11
Subject:
Re: [perl #24204] Dupping STDERR for reading.
Message ID:
20031017161146.32759.qmail@plover.com
Nick Ing-Simmons <nick.ing-simmons@elixent.com>:
> Abigail <abigail@abigail.nl> writes:
> >Furthermore, the ability to open STDERR for reading isn't a Perl specific
> >side-effect; it's a UNIX thing.
> 
> It depends on the UNIX though - some of them are now getting standards
> compliant fussy ...

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.  (!!)

The question was not addressed directly, but according to:

        http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap09.html#tag_09_02

the 'more' command is *required* to open STDERR for reading.  If
opening STDERR for reading doesn't work, then the system cannot
provide a compliant 'more' command and so cannot conform to POSIX.  I
reluctantly conclude that a 'standards compliant fussy' system must
arrange for the stderr file descriptor provided by the shell to be
open in read-write mode.

The relevant excerpt is:

   INPUT FILES
          
     The  input  files  being  examined shall be text files. If standard
     output is a terminal, standard error shall be used to read commands
     from  the user.

I think it's absurd (and I also found a couple of dozen comp.unix.*
articles agreeing) but nevertheless, it is standard.


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About