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.
#!./perl
BEGIN {
- if (!PerlIO::Layer->find('perlio') || $ENV{PERLIO} eq 'stdio') {
- print "1..0 # Skip: not perlio\n";
- exit 0;
- }
if ($^O eq 'VMS') {
print "1..0 # Skip: needs porting, perhaps imitating Win32 mechanisms\n";
exit 0;
{
my $stderr = runperl(
switches => ['-MIPC::Open3', '-w'],
- prog => 'open STDIN, q _Makefile_ or die $!; open3(q _<&1_, my $out, undef, $ENV{PERLEXE}, q _-e0_)',
+ prog => 'open STDIN, q _Makefile_ or die $!; open3(q _<&0_, my $out, undef, $ENV{PERLEXE}, q _-e0_)',
stderr => 1,
);