reading from DATA on win32 with perlio behaves oddly #7207
Comments
From mjcarman@mchsi.comCreated by mjcarman@mchsi.comThis is a bug report for perl from mjcarman@mchsi.com, ----------------------------------------------------------------- Take the following script: #!perl -w Expected output: Actual output: The chomp() and print() don't affect the behavior; they are only used to This works as expected in 5.6.1 but is broken in 5.8.0 and 5.8.3 (and If the source file is in *nix format (not normal, as I'm on WinXP) then If I change 'while' to 'foreach' it works as expected. -mjc Perl Info |
From jeremyd713@hotmail.comCreated by jeremyd713@hotmail.comThis test illustrates the problem: if ($line1 eq "one\n") { print "ok 1\n" } else { print "not ok 1\n" } __DATA__ On a Windows machine with all 5.8 perls that I've tested the second check 1) Comment out the `echo foo` line (and don't mix any sort of piped reads in 2) Set PERLIO=stdio 3) Apply this change to toke.c: Inline Patch--- toke.c.orig Tue Mar 30 23:19:45 2004
+++ toke.c Tue Mar 30 23:19:45 2004
@@ -4153,33 +4153,15 @@
Perl Info |
From jeremyd713@hotmail.comI included a patch with my bug report for #28106. Has anyone more familiar I realize this is still a fairly fresh bug report but it's been causing me Thanks, _________________________________________________________________ |
From @smpeters
I could not replicate the above on a OpenBSD or Mac OS X, but could |
|
The RT System itself - Status changed from 'new' to 'open' |
From @smpeters
I could not replicate the above on a OpenBSD or Mac OS X, but could |
From @smpeters
.NET\FrameworkSDK\bin;C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program
After looking at ticket #27918, I ran into this ticket. This one is the Setting PERLIO to stdio does solve the problem as a workaround. I'm Also, just re-writing the patch to leave Borland and Netware alone would |
|
The RT System itself - Status changed from 'new' to 'open' |
From @smpeters
I can no longer replicate this bug with either bleadperl (compiled with |
|
@smpeters - Status changed from 'open' to 'resolved' |
From @smpetersOn Tue Dec 14 19:01:05 2004, stmpeters wrote:
This now works with a current bleadperl and with ActiveState 5.8.8 build |
|
@smpeters - Status changed from 'open' to 'resolved' |
From @janduboisOn Sat, 16 Dec 2006, Steve Peters via RT wrote:
This problem is not fixed; it still happens with 5.8.8 and blead. It only You'll see this error with the t/op/readline.t test in blead too, if you The backticks are triggering the issue because they will flush all seek(DATA, tell DATA, 0); which should have been a no-op. I was thinking about another way to fix this: Defining the Cheers, |
|
@rgs - Status changed from 'resolved' to 'open' |
From @demerphqThis is a bug report for perl from demerphq@fresh, I downloaded the sources from http://cekirdek.pardus.org.tr/~ismail/dist/perl-5.10.0.tar.gz and for some silly reason unpacked them with WinZip, which apparently did perl -e"$x=bless []; $x.=<>; print $x" did not show a problem. When I noticed the file was in Win32 line endings This is possibly related to perl #38631: tied variables don't work with .= <>, demerphq Flags: Site configuration information for perl 5.10.0: Configured by demerphq at Thu Dec 20 21:27:09 2007. Summary of my perl5 (revision 5 version 10 subversion 0) configuration: Locally applied patches: @INC for perl 5.10.0: Environment for perl 5.10.0: |
From @janduboisOn Thu, 20 Dec 2007, yves orton (via RT) wrote:
No, this error has nothing to do with rcatline; the problem is This bug is a duplicate of http://rt.perl.org/rt3//Public/Bug/Display.html?id=28106. I thought I asked for the bug to be re-opened, but it is still marked as http://groups.google.com/group/perl.perl5.porters/msg/bc743771de29a268 So in summary, I think #27918, #28106 and #48959 are all the same Cheers, PS: Is there a way to get write access to the bug database so I can |
|
The RT System itself - Status changed from 'new' to 'open' |
|
@demerphq - Status changed from 'resolved' to 'open' |
From @demerphqOn 21/12/2007, Jan Dubois <jand@activestate.com> wrote:
Thanks for the explanation. I merged the three bugs together into Cheers, -- |
From brent.shields@ieee.orgHi,
|
From brent.shields@ieee.orgCreated by brent.shields@ieee.orgWhen I use <DATA> to read part of the DATA file and then "tell DATA", the value returned by "tell DATA" is off by the number of newlines that This has been discussed at perlmonks and another experienced programmer agreed that it is likely a bug. I tested it on Knoppix Linux and it does not happen there. Thanks, http://www.perlmonks.com/?node_id=892784 #!/usr/bin/perl my @data_positions = tell(DATA); my @fh_positions; print("@data_positions\n"); __DATA__ __DATA__ ***************************************************** Perl Info |
From @janduboisOn Mon, 14 Mar 2011, via RT wrote:
This is an issue on Perl for Windows only. The problem is that The reason for opening the scripts in binmode (on Windows only) is that Cheers, |
|
The RT System itself - Status changed from 'new' to 'open' |
From @janduboisOn Tue, 15 Mar 2011, Jan Dubois wrote:
Building Perl on Windows with -DPERL_TEXTMODE_SCRIPTS passes all tests c:\tmp>\git\perl\perl data.pl I'll make -DPERL_TEXTMODE_SCRIPTS the default in win32/Makefile and Cheers, |
From @rurban2011/3/16 Jan Dubois <jand@activestate.com>:
As maintainer of ByteLoader I'm of course against core changes which And I never heard so far that ByteLoader has been abandoned, just -- |
From @janduboisOn Wed, 16 Mar 2011, Reini Urban wrote:
I'm not aware of any other source filters that are affected by this. I'm also (so far) just talking about changing the default build
So far I'm not aware of any useful application of ByteLoader. AFAIK If ByteLoader is indeed important, than I would suggest that ByteLoader seek(DATA, 0, 0); Yes, I know it currently doesn't use an explicit marker, like __DATA__, Cheers, |
From @janduboisOn Wed, 16 Mar 2011, Jan Dubois wrote:
I've merged this bug with http://rt.perl.org/rt3//Public/Bug/Display.html?id=28106 which already contained the merged history of 3 related bug reports, I have now changed the default build options for Windows, and added http://perl5.git.perl.org/perl.git/commitdiff/270ca148c As you can see from those tests, the failures aren't restricted to Reading Perl source code in text mode makes all the tests PASS. Cheers, |
From @iabynOn Wed, Mar 16, 2011 at 06:59:11PM -0700, Jan Dubois wrote:
Is it ok to close this ticket? -- |
From @janduboisI consider this "fixed" now (and intend to remove the broken "read |
|
@jandubois - Status changed from 'open' to 'resolved' |
From @janduboisOn Mon, 16 May 2011, Dave Mitchell wrote:
I just "resolved" it. Cheers, |
Migrated from rt.perl.org#28106 (status was 'resolved')
Searchable as RT28106$
The text was updated successfully, but these errors were encountered: