Хз, вроде до moscow.pm должно было дойти
The problem is not in closing fd 0
Let's look at the following sample:
# dup.pl
open my $fh, '<&=',0 or die;
print fileno STDIN, ":", scalar readline STDIN;
close STDIN;
print fileno $fh, ":", scalar readline $fh;
########
bash $ { echo 1; sleep 1; echo 2; } | perl dup.pl
0:1
0:2
(During this I've investigated, that if we do echo -ne "1\n2\n" | perl dup.pl,
then <$fh> receive nothing. I think that's because of buffered read. Don't know
should be this considered a bug)
Then we add the same
open my $fh, '<&=',0 or die;
to the beginning of the example and check the fileno at the end
0 == fileno $fh or die "fileno fh nonzero";
then we will see, that fileno 0 was kept, it still assigned to stdin (this
could be checked additionally), but the behavior of this program still the
same: we got an output of PerlIO.pm
On 09.12.2011, at 16:04, Dmitry Karasik wrote:
> On Fri, Dec 09, 2011 at 03:59:44PM +0400, Mons Anderson wrote:
>>
>> On 09.12.2011, at 15:50, Dmitry Karasik wrote:
>>
>>> нашел, все ясно:
>>>
>>> 1: open( STDIN, '<', \$data ) делает 'require PerlIO::scalar' - т.е.
>>> находит этот PerlIO/scalar.pm и читает его черед fd(0). Ну
>>> читает и слава богу.
>>
>> Фиг. В моем примере, когда мы не даем закрыть fd 0 такого не происходило-бы.
>> А все равно происходит.
>
> в каком примере? и потом, там вполне может быть implicit close
>
> --
> Sincerely,
> Dmitry Karasik
>
> --
> Moscow.pm mailing list
> [email protected] | http://moscow.pm.org
--
Moscow.pm mailing list
[email protected] | http://moscow.pm.org
