From jeremyd713@hotmail.com

Created by Jeremy@jeremyd-home

After upgrading from 5.6.1 to 5.8.3 I noticed that perl now returns the EOF
character (0x1A) as if it were normal data. The 0x1A character in a text
file on Windows marks the end of valid data. Neither it nor what follows
should be returned as data.

It looks like someone already started thinking about this although I
couldn't find an existing bug. perldoc perlio in the :crlf section says​:
  It currently does *not* mimic MS-DOS as far as treating of Control-Z
  as being an end-of-file marker.

This program demonstrates the bug.

open F, "> bug.txt";
binmode(F);
print F "Hello World\x0d\x0a\x1a";
close F;

open F, "bug.txt";
while (<F>) {
  print;
}
close F;

I had to munge the output a bit since I wasn't sure the 0x1A
(displayed on my screen as a right pointing arrow) would make it
safely through perlbug.

C​:\perlbug>c​:\perl-5.6.1-AS635\bin\perl.exe bug.pl
Hello World

C​:\perlbug>c​:\perl-5.8.3-AS809\bin\perl.exe bug.pl
Hello World
(arrow character)
C​:\perlbug>c​:\perl\bin\perl.exe bug.pl
Hello World
(arrow character)

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.8.3:

Configured by Jeremy at Fri Feb 20 07:57:43 2004.

Summary of my perl5 (revision 5 version 8 subversion 3) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef 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='cl', ccflags ='-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE 
-DNO_STRICT -DHAVE_DES_FCRYPT  -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS 
-DUSE_PERLIO -DPERL_MSVCRT_READFIX',
    optimize='-MD -DNDEBUG -O1',
    cppflags='-DWIN32'
    ccversion='', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', 
lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -release  
-libpath:"c:\perl\lib\CORE"  -machine:x86'
    libpth="C:\Program Files\Microsoft Visual Studio .NET\VC7\lib"
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib 
uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib 
msvcrt.lib
    perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  netapi32.lib 
uuid.lib wsock32.lib mpr.lib winmm.lib  version.lib odbc32.lib odbccp32.lib 
msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
    gnulibc_version='undef'
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release  
-libpath:"c:\perl\lib\CORE"  -machine:x86'

Locally applied patches:



@INC for perl v5.8.3:
    c:/perl/lib
    c:/perl/site/lib
    .


Environment for perl v5.8.3:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program 
Files\SecureCRT 3.0
    PERL_BADLANG (unset)
    SHELL (unset)

_________________________________________________________________
Watch high-quality video with fast playback at MSN Video. Free! 
http://click.atdmt.com/AVE/go/onm00200365ave/direct/01/

From @jkeenan

On Mon Feb 23 10​:22​:38 2004, weezel wrote​:

This is a bug report for perl from Jeremy@​jeremyd-home,
generated with the help of perlbug 1.34 running under perl v5.8.3.

-----------------------------------------------------------------
[Please enter your report here]

After upgrading from 5.6.1 to 5.8.3 I noticed that perl now returns
the EOF
character (0x1A) as if it were normal data. The 0x1A character in a text
file on Windows marks the end of valid data. Neither it nor what follows
should be returned as data.

It looks like someone already started thinking about this although I
couldn't find an existing bug. perldoc perlio in the :crlf section says​:
It currently does *not* mimic MS-DOS as far as treating of Control-Z
as being an end-of-file marker.

This program demonstrates the bug.

open F, "> bug.txt";
binmode(F);
print F "Hello World\x0d\x0a\x1a";
close F;

open F, "bug.txt";
while (<F>) {
print;
}
close F;

I had to munge the output a bit since I wasn't sure the 0x1A
(displayed on my screen as a right pointing arrow) would make it
safely through perlbug.

C​:\perlbug>c​:\perl-5.6.1-AS635\bin\perl.exe bug.pl
Hello World

C​:\perlbug>c​:\perl-5.8.3-AS809\bin\perl.exe bug.pl
Hello World
(arrow character)
C​:\perlbug>c​:\perl\bin\perl.exe bug.pl
Hello World
(arrow character)

Is there someone with up-to-date Perl and Windows who could assess the
issues discussed in this older ticket?

Thank you very much.
Jim Keenan

The RT System itself - Status changed from 'new' to 'open'

From @ikegami

On Mon, May 27, 2013 at 8​:55 AM, James E Keenan via RT <
perlbug-followup@​perl.org> wrote​:

Is there someone with up-to-date Perl and Windows who could assess the
issues discussed in this older ticket?

Perl still doesn't treat ^Z specially as of 5.16.2 (and no reason to
believe it's any different in 5.18.0).

  >perl -e"print qq{abc\n\cZ\ndef\n}" >file

  >type file
  abc

  >perl -pe1 file
  abc
  →
  def

  >perl -pe1 <file
  abc
  →
  def

Note that using Ctrl-Z to close STDIN (as you would use Ctrl-D in unix)
works fine.

  >perl -pe1
  abc
  abc
  ^Z

I don't think this is a "feature" we need to implement. While I encountered
a couple of text files with a trailing ^Z back in the days of DOS 3, I've
never encountered such a file since. Windows text editors (e.g. notepad) do
not treat ^Z specially. Even C<type> (used above) only obeys it when
writing to a terminal.

  >type file | perl -pe1
  abc
  →
  def

I don't see any reason to implement it other than "some other libraries do"
(including C's stdio).

- Eric

From @jkeenan

On Mon May 27 10​:21​:08 2013, ikegami@​adaelis.com wrote​:

On Mon, May 27, 2013 at 8​:55 AM, James E Keenan via RT <
perlbug-followup@​perl.org> wrote​:

Is there someone with up-to-date Perl and Windows who could assess the
issues discussed in this older ticket?

Perl still doesn't treat ^Z specially as of 5.16.2 (and no reason to
believe it's any different in 5.18.0).

>perl \-e"print qq\{abc\\n\\cZ\\ndef\\n\}" >file

>type file
abc

>perl \-pe1 file
abc
→
def

>perl \-pe1 \<file
abc
→
def

Note that using Ctrl-Z to close STDIN (as you would use Ctrl-D in unix)
works fine.

>perl \-pe1
abc
abc
^Z

I don't think this is a "feature" we need to implement. While I
encountered
a couple of text files with a trailing ^Z back in the days of DOS 3, I've
never encountered such a file since. Windows text editors (e.g.
notepad) do
not treat ^Z specially. Even C<type> (used above) only obeys it when
writing to a terminal.

>type file | perl \-pe1
abc
→
def

I don't see any reason to implement it other than "some other
libraries do"
(including C's stdio).

- Eric

I'll take that as a YAGNI ... and I'll take the ticket for the purpose
of closing it in seven days unless we get good arguments to the contrary.

Thanks for looking into this.

Jim Keenan

From @jkeenan

On Mon May 27 16​:09​:09 2013, jkeenan wrote​:

I'll take that as a YAGNI ... and I'll take the ticket for the purpose
of closing it in seven days unless we get good arguments to the contrary.

Thanks for looking into this.

Jim Keenan

Closing as per schedule. Thank you very much.

@jkeenan - Status changed from 'open' to 'resolved'