in reply to Re: ActiveState woes : Is it EOF-blind?
in thread ActiveState woes : Is it EOF-blind?

Sending chr(0x1a) has no effect for me. It doesn't work if I follow it with \n either. It gets successfully echoed back by cat and shows up as an arrow on the screen.

Even though I didn't expect it to work, I had tried that earlier. Perl doesn't treat chr(0x1A) specially, only CRLF.

Replies are listed 'Best First'.
Re^3: ActiveState woes : Is it EOF-blind?
by tachyon-II (Chaplain) on May 06, 2008 at 02:43 UTC

    By has no effect what do you mean? With the reader loop as written, on Win32, without the 0x1a it gets both lines, then hangs (blocks), awiating EOF. With the 0x1a it detects the end of the input and then finishes. Tested on Win2k SP2, AS perl 5.6.1

    To get it to run as written on Linux (CentOS) perl 5.10 you need to close $wtr. Sending 0x1a makes no difference.

    [james@adajio ~]$ cat cat.pl $|++; print while <>; [james@adajio ~]$ cat ipc.pl #!/usr/bin/perl use strict; use IPC::Open2; $|++; my $EOF = ''; # chr(0x1a); # inline use "\x1a" my $perl = "/usr/bin/perl"; my $cat = "/home/james/cat.pl"; my $data = "first line\nsecond line"; my $pid = open2(my $rdr, my $wtr, $perl, $cat ); print "Sending:\n$data\n----\n"; print $wtr $data .$EOF; close $wtr; print "Going for read!\n"; print while <$rdr>; [james@adajio ~]$ ./ipc.pl Sending: first line second line ---- Going for read! first line second line [james@adajio ~]$

    So on linux the act of closing $wtr effectively sends the EOF signal. Physically sending apparently does nothing. Sending a \n at the end of the $data string allows reading of the second line but it still hangs awaiting EOF. Thus a portable way of doing it is to send the EOF (makes it work on Win32) and close $wtr (makes it work on *nix) - as this ensures perl gets a detectable EOF into the $rdr stream.

      By has no effect what do you mean?

      I mean it doesn't change the outcome. The program behaves as if it wasn't there. It hangs.

      Tested on Win2k SP2, AS perl 5.6.1

      Well that's different. Various ActiveState builds on WinXP:
      VersionBuildResult w/o EOFResult w/ EOF
      5.6.0Active State build 623HangsProgram ends as desired
      5.6.1Active State build 635HangsProgram ends as desired
      5.8.0Active State build 806HangsHangs
      5.8.8Active State build 817HangsHangs
      5.10.0Active State build 1001HangsHangs

      I suspect you'd get the same results on Win2k.

      This is why:

      >debug
      -e100 "abc",0D,0A,1A,0D,0A,"def",0D,0A
      -rcx
      CX 0000
      :0D
      -ntest
      -w
      Writing 0000D bytes
      -q
      
      >c:\progs\perl560\bin\perl -ple1 test
      abc
      
      >c:\progs\perl561\bin\perl -ple1 test
      abc
      
      >c:\progs\perl580\bin\perl -ple1 test
      abc
      →
      def
      
      >c:\progs\perl588\bin\perl -ple1 test
      abc
      →
      def
      
      >c:\progs\perl5100\bin\perl -ple1 test
      abc
      →
      def
      

      More specifically, it's probably related to the introduction of PerlIO.

      >c:\progs\perl560\bin\perl -V | find /i "perlio"
          useperlio=undef d_sfio=undef uselargefiles=undef
      
      >c:\progs\perl561\bin\perl -V | find /i "perlio"
          useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef
      
      >c:\progs\perl580\bin\perl -V | find /i "perlio"
          useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
          cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -
      DNO_STRICT -DHAVE_DES_FCRYPT  -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_
      PERLIO -DPERL_MSVCRT_READFIX',
      
      >c:\progs\perl588\bin\perl -V | find /i "perlio"
          useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
          cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -
      DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_
      CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
                              USE_PERLIO USE_SITECUSTOMIZE
      
      >c:\progs\perl5100\bin\perl -V | find /i "perlio"
          useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
          cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -
      DNO_STRICT -DHAVE_DES_FCRYPT -DUSE_SITECUSTOMIZE -DPRIVLIB_LAST_IN_INC -DPERL_IM
      PLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
                              USE_LARGE_FILES USE_PERLIO USE_SITECUSTOMIZE
      

      Perl shouldn't have to treat \x1A specially (since it's only needed when reading from the console which is handled by the system) and it *must not* treat \x1A specially in some cases (such as when the encoding is UTF-16 or when the input can be "binary"), so I believe PerlIO is *correct* and there's actually a bug somewhere and this whole \x1A thing is a workaround that no longer works.

        Actually, newer versions of perl have broken the 'proper' behaviour of text mode on Win32. Relative to the system utilities anyway. Historically, ^Z was used to indicate the end of file in text files whose content failed to fill the last allocation block on disc on filesystems that didn't have room in their directory structures for a number to determine this information. And whilst the reason for using ^Z has fallen into history, the system utilities still honour this mechanism(*).

        If you create a text file that contains a ^Z part way through:

        C:\test>perl -wle" print 'the quick brown fox' for 1..3; print chr( 26 ); print 'secret message' " > junk.txt

        And then use a system utility to display it:

        C:\test>type junk.txt the quick brown fox the quick brown fox the quick brown fox

        The system utitlties stop reading when they encounter the ^Z, just like in days of yore.

        Perl used to honour this in 5.6.1 days, but has since broken the behaviour:

        C:\test>perl -pe1 junk.txt the quick brown fox the quick brown fox the quick brown fox &#8594; secret message

        translation to unicode entity the result of posting of course

        Perl shouldn't read past a ^Z unless the file has been binmode'd. And yes, a consquence of this is that when reading unicode files, they should be read in binary mode.

        I don't suppose that a 'bug' report for this would rate much attention. If the world has survived the 5(more?) years of 5.8.x without noticing this, then I don't expect much action to be taken now. But can you imagine the storm if Perl for *nix suddenly started to doing line-end translation unless you used binmode :)

        (*)As a historical aside, when Mike Cowlishaw ported REXX to OS/2, he used this feature to good effect. The first time a REXX program was run, the 'compiled' binary bytecode was attached to the end of the file after the ^Z. On subsequent runs, if the bytecode was still there, it would be used rather than recompiling. As all the editors and system utilities used the MS CRT to read the files, whenever a file was copied or editied, the bytecode was transparently discarded and so it would be re-compiled whenever it was modified.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.