I don't believe it is. If you think it is, then present some evidence.
Come to think of it, I'd be surprised if this were the problem at 488 characters. 512 I could believe. But perhaps it is printing out some other stuff?
With the few precise details provided, it is a big guessing game.
| [reply] |
The exact code looks like:
my( $write, $read, $error, $pid );
if( $is_win32 )
{
print "here2\n";
open my $file, "<", $_ or warn "Can't open $_ for read
+ing"; #log
chomp( my $shebang = <$file> );
close $file;
warn "Bad shebang: $shebang - $_" unless $shebang =~ s
+/^\#!//; #log #shitty highlighting
#warn "$shebang $_"; #log
print "here 3\n";
print "$shebang $_",$/;
eval{ $pid = open3( $write, $read, $error, $shebang, $
+_ ) };
print "here 4\n";
}
I have buffering turned off and when I run that snippet I get:
here2
here 3
perl usr/test.pl
Where "perl usr/test.pl" is the $shebang $_ line. usr/test.pl looks like:
#!perl
print "x" x 489;
If I change the 489 to 488, everything works perfectly. However, this is run from a forked subprocess, which is apparently causing the error, as when I run that open3 line from the command line via perl -e, it works perfectly, so theres something screwy with multiple forks.
For example, this command line invocation seems to (randomly?) hang
D:\home\buu\pas>perl -le"use IPC::Open3 qw/open3/; fork; fork; print $$; open3($w, $r, $e, 'perl', 'usr/test.pl'); print <$r>"
With test.pl being the same as I quoted above.
| [reply]
[d/l]
[select] |
Heh. demerphq was right after all. Using the emulated fork of Win32 Perl makes things very flakey (at least the last time I tried, which was after I was told "Oh, we fixed all those bugs" but it was still extremely buggy just like the previous few times when I heard "Oh, we fixed all those bugs").
Maybe it is only somewhat flakey now. But I would recommend you not use it.
| [reply] |