Closed p5pRT closed 20 years ago
The following program should either die()\, print a warning\, or print "foo". Instead it prints nothing:
#!/usr/bin/perl -w
use strict;
open(F\, "\<&DATA") || die "open: $!\n";
print \
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
on my linux box it prints "foo".
opi:\~ # perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux\, osvers=2.4.19\, archname=i586-linux-thread-multi uname='linux bloembergen 2.4.19 #1 mon apr 15 08:57:26 gmt 2002 i686 unknown ' config_args='-ds -e -Dprefix=/usr -Dusethreads -Di_db -Di_dbm -Di_ndbm - -Di_gdbm -Duseshrplib=true' hint=recommended\, useposix=true\, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='cc'\, ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing - -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\, optimize='-O3 --pipe'\, cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing' ccversion=''\, gccversion='3.2'\, gccosandvers='' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=1234 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=4\, prototype=define Linker and Libraries: ld='cc'\, ldflags ='' libpth=/lib /usr/lib /usr/local/lib libs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil libc=\, so=so\, useshrplib=true\, libperl=libperl.so gnulibc_version='2.2.5' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-rdynamic - -Wl\,-rpath\,/usr/lib/perl5/5.8.0/i586-linux-thread-multi/CORE' cccdlflags='-fPIC'\, lddlflags='-shared'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Sep 9 2002 18:13:56
@INC:
/usr/lib/perl5/5.8.0/i586-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
.
opi:\~ # perl
#!/usr/bin/perl -w
use strict;
open(F\, "\<&DATA") || die "open: $!\n";
print \
On Tuesday 22 April 2003 02:05\, Josh Purinton (via RT) wrote:
# New Ticket Created by Josh Purinton # Please include the string: [perl #22010] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22010 >
The following program should either die()\, print a warning\, or print "foo". Instead it prints nothing:
#!/usr/bin/perl -w use strict; open(F\, "\<&DATA") || die "open: $!\n"; print \
; __DATA__ foo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+pVw5wicyCTir8T4RAvl7AJ9Hl0yixCNDcWYXfdlwwxjNrf38WQCgxno5 Du/uxQY3VPC3BajaIFzd2MQ= =77yM -----END PGP SIGNATURE-----
On Tue\, Apr 22\, 2003 at 03:40:09PM -0000\, torsten.foertsch@gmx.net (via RT) - perlbug-followup@perl.org wrote:
on my linux box it prints "foo".
Interesting. Mine too\, when I enter the script from standard input like that. Try putting the script in a file\, and running perl file.pl.
-- Josh Purinton \josh@​purinton\.org "Stuff I have no clue about in e.g. libc's crt0.S is left out\, like the stuff for padding the caller's stack frame. I just hope they were kidding." --Rick Hohensee in libsys/arg_env.c
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 22 April 2003 17:45\, Josh Purinton wrote:
On Tue\, Apr 22\, 2003 at 03:40:09PM -0000\, torsten.foertsch@gmx.net (via RT)
- - perlbug-followup@perl.org wrote:on my linux box it prints "foo".
Interesting. Mine too\, when I enter the script from standard input like that. Try putting the script in a file\, and running perl file.pl.
That one prints "foo" in both cases and as "cat x.pl | perl" too:
#!/usr/bin/perl -w
use strict;
open(F\, "\<&=DATA") || die "open: $!\n";
print \
__DATA__ foo
The only difference is "\<&=DATA" vs. "\<&DATA".
Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+pX0pwicyCTir8T4RAiUhAKCf1fDRUgc07dOpfKI9xxz3aHKo8wCfaGht cdR6MGNZ2WvmAVgzLfeQ/20= =s0wc -----END PGP SIGNATURE-----
On Tue\, Apr 22\, 2003 at 07:34:28PM +0200\, Torsten Foertsch - torsten.foertsch@gmx.net wrote:
That one prints "foo" in both cases and as "cat x.pl | perl" too:
#!/usr/bin/perl -w use strict; open(F\, "\<&=DATA") || die "open: $!\n"; print \
; __DATA__ foo
The only difference is "\<&=DATA" vs. "\<&DATA".
Amazing. According to 'perldoc -f open'\, '\<&=' is supposed to be followed by a file descriptor\, not a file handle name. In any event\, neither of my two perl installations behave like yours (i.e.\, they both print nothing).
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=openbsd\, osvers=3.1\, archname=i386-openbsd uname='openbsd' config_args='-Dopenbsd_distribution=defined -dsE' hint=recommended\, useposix=true\, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc'\, ccflags ='-fno-strict-aliasing -I/usr/local/include'\, optimize='-O2'\, cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion=''\, gccversion='2.95.3 20010125 (prerelease)'\, gccosandvers='openbsd3.1' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=1234 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=4\, usemymalloc=n\, prototype=define Linker and Libraries: ld='cc'\, ldflags ='' libpth=/usr/lib libs=-lm -lc -lutil perllibs=-lm -lc -lutil libc=/usr/lib/libc.so.28.3\, so=so\, useshrplib=true\, libperl=libperl.so.6.1 Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=define\, ccdlflags=' ' cccdlflags='-DPIC -fPIC '\, lddlflags='-shared -fPIC '
Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under openbsd Compiled at Aug 21 2002 16:05:29 @INC: /usr/libdata/perl5/i386-openbsd/5.6.1 /usr/local/libdata/perl5/i386-openbsd/5.6.1 /usr/libdata/perl5 /usr/local/libdata/perl5 /usr/local/libdata/perl5/site_perl/i386-openbsd /usr/libdata/perl5/site_perl/i386-openbsd /usr/local/libdata/perl5/site_perl /usr/libdata/perl5/site_perl /usr/local/lib/perl5/site_perl
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux\, osvers=2.4.16-010stab017.5.777-smp\, archname=i686-linux uname='linux lambda.purinton.org 2.4.16-010stab017.5.777-smp #1 smp tue feb 4 00:18:35 msk 2003 i686 unknown ' config_args='' hint=recommended\, useposix=true\, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n\, bincompat5005=undef Compiler: cc='cc'\, ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\, optimize='-O2'\, cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion=''\, gccversion='2.96 20000731 (Red Hat Linux 7.3 2.96-113)'\, gccosandvers='' intsize=4\, longsize=4\, ptrsize=4\, doublesize=8\, byteorder=1234 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=12 ivtype='long'\, ivsize=4\, nvtype='double'\, nvsize=8\, Off_t='off_t'\, lseeksize=8 alignbytes=4\, prototype=define Linker and Libraries: ld='cc'\, ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.5.so\, so=so\, useshrplib=false\, libperl=libperl.a gnulibc_version='2.2.5' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-rdynamic' cccdlflags='-fpic'\, lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Mar 13 2003 18:44:31 @INC: /package/perl-5.8.0/lib/5.8.0/i686-linux /package/perl-5.8.0/lib/5.8.0 /package/perl-5.8.0/lib/site_perl/5.8.0/i686-linux /package/perl-5.8.0/lib/site_perl/5.8.0 /package/perl-5.8.0/lib/site_perl . . -- Josh Purinton \perlbug20030421\.5\.jp@​xoxy\.net "Stuff I have no clue about in e.g. libc's crt0.S is left out\, like the stuff for padding the caller's stack frame. I just hope they were kidding." --Rick Hohensee in libsys/arg_env.c
Abhijit Menon-Sen discovered that the behavior depends on PERLIO.
$ PERLIO=stdio perl test $ PERLIO=perlio perl test foo $
-- Josh Purinton
On Tue\, Apr 22\, 2003 at 10:48:44AM -0700\, Josh Purinton wrote:
On Tue\, Apr 22\, 2003 at 07:34:28PM +0200\, Torsten Foertsch - torsten.foertsch@gmx.net wrote:
That one prints "foo" in both cases and as "cat x.pl | perl" too:
#!/usr/bin/perl -w use strict; open(F\, "\<&=DATA") || die "open: $!\n"; print \
; __DATA__ foo
The only difference is "\<&=DATA" vs. "\<&DATA".
Amazing. According to 'perldoc -f open'\, '\<&=' is supposed to be followed by a file descriptor\, not a file handle name. In any event\, neither of my two perl installations behave like yours (i.e.\, they both print nothing).
And file descriptors are numbers. "DATA" in numeric context is 0. And if I replace "\<&=DATA" with "\<&=0"\, I get the same output. Using "\<&0" gives the same as well.
Abigail
On Tue\, Apr 22\, 2003 at 08:19:32PM -0000\, abigail@abigail.nl (via RT) - perlbug-followup@perl.org wrote:
And file descriptors are numbers. "DATA" in numeric context is 0. And if I replace "\<&=DATA" with "\<&=0"\, I get the same output. Using "\<&0" gives the same as well.
Odd. \<&0 should mean from descriptor 0\, which under most shells is standard input. Why would input on descriptor 0 be reading from DATA?
-- Josh Purinton
On Tue\, Apr 22\, 2003 at 08:45:51AM -0700\, Josh Purinton wrote:
On Tue\, Apr 22\, 2003 at 03:40:09PM -0000\, torsten.foertsch@gmx.net (via RT) - perlbug-followup@perl.org wrote:
on my linux box it prints "foo".
Interesting. Mine too\, when I enter the script from standard input like that. Try putting the script in a file\, and running perl file.pl.
That may be silly\, but does it still print nothing if you give perl the -l flag\, or add another line after 'foo' ?
Regards Adi
On Tue\, Apr 22\, 2003 at 09:32:49PM -0000\, Adrian Enache (via RT) - perlbug-followup@perl.org wrote:
That may be silly\, but does it still print nothing if you give perl the -l flag\, or add another line after 'foo' ?
It still prints nothing with -l. As I mentioned earlier\, the problem is only happens with PERLIO=stdio.
On Tue\, Apr 22\, 2003 at 02:40:16PM -0700\, Josh Purinton wrote:
On Tue\, Apr 22\, 2003 at 09:32:49PM -0000\, Adrian Enache (via RT) - perlbug-followup@perl.org wrote:
That may be silly\, but does it still print nothing if you give perl the -l flag\, or add another line after 'foo' ?
It still prints nothing with -l. As I mentioned earlier\, the problem is only happens with PERLIO=stdio.
Sorry\, I haven't read all the thread. I can reproduce it with bleadperl / :stdio\, but only with a threaded perl:
ratsnest$ PERLIO=stdio perl t.pl ratsnest$ PERLIO=stdio perl-nonthr t.pl foo
Regards Adi
On Wed\, Apr 23\, 2003 at 12:55:47AM +0300\, I wrote:
I can reproduce it with bleadperl / :stdio\, but only with a threaded perl:
ratsnest$ PERLIO=stdio perl t.pl ratsnest$ PERLIO=stdio perl-nonthr t.pl foo
Oops\, that may be inexact\, since that perl-nonthr is built with useperlio=undef ..
Regards Adi
Josh Purinton \perl5\-porters@​perl\.org writes:
# New Ticket Created by Josh Purinton # Please include the string: [perl #22010] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22010 >
The following program should either die()\, print a warning\, or print "foo". Instead it prints nothing:
How so? You have dup'ed a file handle to the current position of *DATA. But at the point you do the "dup" the file pointer of DATA is at EOF. If you read DATA itself you will get 'foo' from the buffer\, but if you read your dup-ed *F it hasn't copied the buffer data so it tries to read a buffer at current position and gets EOF.
#!/usr/bin/perl -w use strict; open(F\, "\<&DATA") || die "open: $!\n"; print \
; __DATA__ foo
-- Nick Ing-Simmons http://www.ni-s.u-net.com/
On Wed\, Apr 23\, 2003 at 04:12:27PM -0000\, Nick Ing-Simmons wrote:
You have dup'ed a file handle to the current position of *DATA. But at the point you do the "dup" the file pointer of DATA is at EOF. If you read DATA itself you will get 'foo' from the buffer\, but if you read your dup-ed *F it hasn't copied the buffer data so it tries to read a buffer at current position and gets EOF.
'PERLIO=stdio perl test' prints 'foo'. 'PERLIO=perlio perl test' prints nothing.
Which is correct?
Josh Purinton \perlbug20030421\.5\.jp@​xoxy\.net writes:
On Wed\, Apr 23\, 2003 at 04:12:27PM -0000\, Nick Ing-Simmons wrote:
You have dup'ed a file handle to the current position of *DATA. But at the point you do the "dup" the file pointer of DATA is at EOF. If you read DATA itself you will get 'foo' from the buffer\, but if you read your dup-ed *F it hasn't copied the buffer data so it tries to read a buffer at current position and gets EOF.
'PERLIO=stdio perl test' prints 'foo'. 'PERLIO=perlio perl test' prints nothing.
I would have expected that to be other way round.
Which is correct?
Both ;-)
-- Nick Ing-Simmons http://www.ni-s.u-net.com/
On Thu\, Apr 24\, 2003 at 02:25:42PM -0000\, Nick Ing-Simmons wrote:
'PERLIO=stdio perl test' prints 'foo'. 'PERLIO=perlio perl test' prints nothing. I would have expected that to be other way round.
Oops\, it is the other way around. My mistake.
Which is correct? Both ;-)
Fair enough. Currently perldata.pod simply states: The filehandle is left open pointing to the contents after __DATA__.
It might help to add a warning like: Unlike all other filehandles\, DATA is read by perl while reading the program. Hence\, the operating system's file pointer for DATA may point past the beginnning of the contents after __DATA__\, even when a program has not explicitly read from DATA. Consider calling C\<sysseek(*DATA\, tell(*DATA)\, 0)> before calling low-level IO functions on DATA (such as C\<sysread(DATA\, ...)> or C\<open(...\, "\<&DATA")>)
Josh Purinton \perlbug20030421\.5\.jp@​xoxy\.net writes:
On Thu\, Apr 24\, 2003 at 02:25:42PM -0000\, Nick Ing-Simmons wrote:
'PERLIO=stdio perl test' prints 'foo'. 'PERLIO=perlio perl test' prints nothing. I would have expected that to be other way round.
Oops\, it is the other way around. My mistake.
Which is correct? Both ;-)
Fair enough. Currently perldata.pod simply states: The filehandle is left open pointing to the contents after __DATA__.
It might help to add a warning like: Unlike all other filehandles\, DATA is read by perl while reading the program.
But it isn't really unlike other file handles. The "read by perl" part is true and what causes the "problem". In general a dup() like the subject uses will give odd results if original file handle has been read (or written).
Hence\, the operating system's file pointer for DATA may point past the beginnning of the contents after __DATA__\, even when a program has not explicitly read from DATA. Consider calling C\<sysseek(*DATA\, tell(*DATA)\, 0)> before calling low-level IO functions on DATA (such as C\<sysread(DATA\, ...)> or C\<open(...\, "\<&DATA")>)
True in general which is why there are warnings about mixing sysread() with normal IO in the docs.
-- Nick Ing-Simmons http://www.ni-s.u-net.com/
On Sun\, Apr 27\, 2003 at 07:52:29PM -0000\, Nick Ing-Simmons wrote:
Fair enough. Currently perldata.pod simply states: The filehandle is left open pointing to the contents after __DATA__.
It might help to add a warning like: Unlike all other filehandles\, DATA is read by perl while reading the program.
But it isn't really unlike other file handles.
Interesting. What other file handles does the perl interpreter read from without the script explicitly requesting it? (And where is this behavior documented?)
-- Josh Purinton \perlbug20030421\.5\.jp@​xoxy\.net
Josh Purinton \perlbug20030421\.5\.jp@​xoxy\.net writes:
On Sun\, Apr 27\, 2003 at 07:52:29PM -0000\, Nick Ing-Simmons wrote:
Fair enough. Currently perldata.pod simply states: The filehandle is left open pointing to the contents after __DATA__.
It might help to add a warning like: Unlike all other filehandles\, DATA is read by perl while reading the program.
But it isn't really unlike other file handles.
Interesting. What other file handles does the perl interpreter read from without the script explicitly requesting it? (And where is this behavior documented?)
It depends what you thought I meant. I was just saying that any file handle which is buffered by stdio will have file position "wrong" when used as in Subject: line e.g. consider:
#!perl open(FOO\,__FILE__); my $a = getc(FOO); open(BAR\,"\<&FOO"); print "FOO="\,tell(FOO)\," BAR="\,tell(BAR)\,"\n"; __END__
We have "read" one character (and my locale as such that that means 1 byte) but that does NOT mean that the numeric fd's file posn is 1. When I run that on my 5.8 (which defaults to :stdio)
perl /tmp/x FOO=1 BAR=124 nick@bactrian 1003$
But :perlio "fixes" it:
nick@bactrian 1003$ PERLIO=perlio perl /tmp/x FOO=1 BAR=1 nick@bactrian 1004$
-- Nick Ing-Simmons http://www.ni-s.u-net.com/
On Wed\, Apr 30\, 2003 at 12:34:53PM -0000\, Nick Ing-Simmons wrote:
any file handle which is buffered by stdio will have file position "wrong" when used as in Subject: line
Not exactly. Without the getc()\, your example will print "FOO=0 BAR=0" for any file handle except DATA.
#!perl open(FOO\,__FILE__); my $a = getc(FOO); open(BAR\,"\<&FOO"); print "FOO="\,tell(FOO)\," BAR="\,tell(BAR)\,"\n"; __END__
Normally\, until the script explicitly reads/writes/seeks from F (or explicitly passes F to another process that does so)\, tell(F) == sysseek(F\, 0\, 1). With DATA however\, this is not guaranteed. How about documenting this difference?
-- Josh Purinton \perlbug20030421\.5\.jp@​xoxy\.net
Josh Purinton \perlbug20030421\.5\.jp@​xoxy\.net writes:
On Wed\, Apr 30\, 2003 at 12:34:53PM -0000\, Nick Ing-Simmons wrote:
any file handle which is buffered by stdio will have file position "wrong" when used as in Subject: line
Not exactly. Without the getc()\, your example will print "FOO=0 BAR=0" for any file handle except DATA.
(Actually it is _exactly_ due to my weasle words "which is buffered by stdio". The getc() is just the way I chose to call that buffer into being.)
#!perl open(FOO\,__FILE__); my $a = getc(FOO); open(BAR\,"\<&FOO"); print "FOO="\,tell(FOO)\," BAR="\,tell(BAR)\,"\n"; __END__
Normally\, until the script explicitly reads/writes/seeks from F (or explicitly passes F to another process that does so)\, tell(F) == sysseek(F\, 0\, 1). With DATA however\, this is not guaranteed. How about documenting this difference?
I have no objection to that at all.
What I have been arguing about is making it clear that is the read()-ing that caused the "problem". The read()s may be _implcit_ for DATA but any handle that has been read() is subject to the "bug".
-- Nick Ing-Simmons http://www.ni-s.u-net.com/
Migrated from rt.perl.org#22010 (status was 'resolved')
Searchable as RT22010$