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 16, 2003 15:12
Re: [perl #24204] Dupping STDERR for reading.
Message ID:
Abigail <>:
> On Tue, Oct 14, 2003 at 11:35:00PM -0400, Mark Jason Dominus wrote:
> > 
> > The idea sounds pretty hokey to me, and less reliable than just
> > opening /dev/tty.
> Whether or not it's hokey isn't the point. 

It might be.  I don't know what the situation is, but I suppose that
the breakage occurs because the perl 5.8 in question is using PerlIO
and the older perls are not.

If dup'ing STDERR and reading the result was always a nonportable
platform- or library-dependent feature, then the fact that it has been
broken in someone's perl build by their switch to PerlIO is not
something that I think we need to be concerned about.

Here's an analogy.  On many systems, one cannot open a directory as if
it were a regular file; the open() call fails, or the open() succeeds
but the read() calls return end-of-file immediately.  On other
systems, one can read the binary data out of the directory as if it
were a regular file.  But this is an undocumented feature, and
programmers are supposed to use opendir() and readdir().

Suppose Fred has a Perl program which opens a directory and reads the
binary data out of it for whatever purpose.  This works for Fred.
Then Fred upgrades to 5.8.0 and find out that because of a change in
Perl, his program no longer works.

We could fix this, but doing so is risky.  This is because a month
later, Fred might upgrade his operating system and find that his
program has broken again.  And this time there is nothing that Perl
can do about it.  The time and effort put into fixing Perl to allow
the dubious usage was wasted.

Reading of binary data from directory files is hokey in the sense that
I intended above.  It is not something that anyone is supposed to be
doing, and if it works, it works by accident.  It is undocumented and
unsupported, and there is a clearly advertised alternative interface
for doing the same thing.

I don't know for sure, but I believe that opening STDERR for reading
in an attempt to get the terminal device is hokey in this sense.   I

  * It it not something that anyone is supposed to be doing

  * If it works, it works by accident

  * It is undocumented and unsupported

  * There is a clearly advertised alternative for doing the same thing
    (If you want to open the terminal device for reading, then you
     open /dev/tty for reading--perfectly straightforward.)

  * Fixing whatever change in Perl caused this is risky because an
    entirely unrelated shell or OS change could break the behavior
    again at any time
I might be mistaken about any of these.  But if I'm correct, then I
think the response to this 'bug' is to ignore it.

I hope this clears up what I meant by 'hokey' and why I thought it was
relevant that reading from STDERR might be 'hokey'.

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