From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021016 Description of problem: I've attached a script -- matching [^\s] works on a string literal containing simple ascii (no code, no accented chars). That same string, after being written and read from a file, prints OK, but the [^\s] match fails. If the match is changed to [\S] or \S, the match works on the string read from the file. The script works OK if LC_ALL=POSIX is put in the environment or if binmode is used on the file for input. I've compiled a new perl in the meantime, using all default options, and the problem goes away. But on the perl that comes with the redhat distribution the problem is there. The script: ---------------------------------------------- my $x = "this\n"; open(F, ">/tmp/test.txt"); print F "$x"; close(F); open(F, "</tmp/test.txt"); my @lines = <F>; close(F); if ($x =~ /^\s*([^\s]+)/) { print "'$x' internal string matched OK\n"; } else { print "'$x' internal string FAILED!\n"; } for $x (@lines) { if ($x =~ /^\s*([^\s]+)/) { print "'$x' file string matched OK\n"; } else { print "'$x' file string FAILED!\n"; } } Version-Release number of selected component (if applicable): perl-5.8.0-88 How reproducible: Always Steps to Reproduce: 1.install redhat 9 2.run the above script 3. Actual Results: 'this ' internal string matched OK 'this ' file string FAILED! Expected Results: 'this ' internal string matched OK 'this ' file string matched OK Additional info: *any* of the following make the script work: - LC_ALL=POSIX in the environment. - use binmode(F) on the input file. - change [^\s] to [\S] or \S.
This bug also causes the muttprint (http://muttprint.sourceforge.net/) failure on RH9. According to the muttprint home page the Perl in rawhide works OK (I have not verified this though).
This error causes CGI.pm to fail in offline debugging mode, since the module reads from STDIN in that case. When used in this fashion, the program hangs when the input data is passed from CGI.pm to shellword.pl for parsing (where the pattern [^\s\\'"] is used), making it appear to the user as though ^D fails to end keyboard input. The problem seems to affect all character classes with negated escape sequences, not just [^\s], as can be seen in the following: -------------------------- $_ = "somestring"; open OUTF, ">testdata.$$" or die; print OUTF $_; close OUTF; open INF, "<testdata.$$" or die; # uncomment the next line to recreate the problem # $_ = <INF>; close INF; /[^\d]+/ ? print "pattern succeeded\n" : print "pattern failed\n"; -------------------------- The fix "export LC_ALL=POSIX" mentioned above works to correct this problem in all the cases I've tested.
I know this thing's languished a MONTH with no change/comment, but in case it's still a problem for you, rumour has it that the RawHide release of perl has a mod that fixes this anomaly-not-bug . Give it a try and maybe let Chip cross this thing off his massive to-do list? I'll be trying it in a bit, for about 4 similar problems I'm having with the perl 580-88 on RHL9 - it's like this perl Unicode thing's causing almost as much grief and pain as the Kerberos-devel feature-not-bug.
This bug was apparently fixed in perl-5.8.0-88.3 (rh9-updates, build date 2003-08-13). Can someone close it please ?
This bug is fixed in all current Red Hat perl releases - closing.