This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
The test for #76474 should open file descriptor 0, not 1.
authorNicholas Clark <nick@ccl4.org>
Fri, 1 Jul 2011 07:28:20 +0000 (09:28 +0200)
committerNicholas Clark <nick@ccl4.org>
Wed, 6 Jul 2011 20:39:47 +0000 (22:39 +0200)
commit2db249d3d6f61a44bb2e6dd90d24085003da650c
treefaa3a14fc7badc2a8c2f3c5a065f5493eeab2caf
parent95483f2ef1346f4eb87ae502da49c281d40d1c44
The test for #76474 should open file descriptor 0, not 1.

The original bug report states

    if we try to dup STDIN in a child process by using it's file descriptor

but has code to dup 1, not 0:

    perl -MIPC::Open3 -wle 'open3("<&1", my $out, undef, $^X)'

Change the above code to "<&0" and the same bug is demonstrated, and fixed by
the relevant change.

However, trying to open descriptor 1 for input causes subtle portability
problems, which conceal the actual bug we're attempting to test. On most
platforms the terminal is read write, and a command tested on the command line
actually has file descriptor 1 read/write (and probably file descriptor 0 also)

When the output is being piped, for example in a test checking the output,
descriptor 1 is (likely to be) write only. PerlIO is quite happy to *open* a
such a numeric file descriptor for reading, and will only generate an error if
an actual read is attempted (which this test does not). stdio (on several
platforms tested) fails the *open* in the same scenario. Hence whether this
*test* passed or failed depended on the IO system used, which is actually not
what we want to test.

Original test added in a0ed8b7b5f7f6d6f, fix added in fb9b5b31d8a62644.
ext/IPC-Open3/t/fd.t