If you have a newer Perl (5.8 definitely, maybe 5.6 too) and are using a UTF-8 locale, you will get many warnings from perl about "Malformed UTF-8 character" warnings. This is because the HTML output currently uses latin1, which doesn't validate as UTF-8 (unless I am mistaken, this would occur for any input that didn't validate against the locale's encoding even without a UTF-8 locale).

This problem can be worked around by telling perl to treat the input data as byte data rather than character data by adding the "use bytes;" pragma.

"When you are faced with a dilemma, might as well make dilemmanade. "

I *WAS* using "=" instead of "=~" like an idiot. Didn't help much though.

"use bytes" solved the problem. Strange thing is, this is all on a terminal (no HTML) so not sure why it's doing this. The ONLY thing I can think of different is that the machine w/ the dodgy output has apache running on it, but I'm running this script off to the side.

Thanks

You say you are not really doing any utf8 stuff, but it would appear that your text file contains non-ASCII data (e.g. latin1 "accented" characters). If the file uses the "upper table" of iso-8859-1, then the "0xb2" byte is a superscript "2". If it's some other character set, then it's probably some other "special" character. Or maybe it's just noisy data...

In any case, upgrading to 5.8.2 (the current version) will help. 5.8.0's "interpretive preference" based on the locale setting was ultimately viewed as a bad idea, and was changed in 5.8.1.

You know what. I never thought about the input. I'm using a file that's created by someone other than me. That person happens to be from another country (that uses the accented characters and eat bagettes)... I'll bet someone a coke that that's it.

For the record, the machine that it DOES work on, is my machine -- has canna and kinput2 running at all time, and I go in and out of Japanese. The machine it doesn't work on is English only.

Either way, the text file is an absolute mess, which is why I'm working on it in the first place.

Cheers to everyone for their input!

AM,

I believe your regex is ok (your use of $_ may be somewhat mistaken, but that may be just due to a "quickie" example type-up.

On 5.6.1, under Win32, I got the expected result from

echo 5* | perl -e "while (<>) {print $_ if /\d{1,}\*/}"
[download]

No answers for you beyond this...(perhaps I missed something???)

,welchavw

Though I know little in the way of Unicode, it seems to me that somewhere Perl thinks something in your regex is trying to specify a UTF-8 character when you aren't; are you using UTF-8 other places in the script? What version of perl are you using?

Just as a side note, {1,} can be written more succintly as +, like thus: /\d+\*/

It thinks so, but I'm not using Unicode anywhere. Here's the whole script.

#!/usr/bin/perl
#
#
use strict;
use warnings;

my $file = "input.txt";

open ( FILE, $file ) || die "Can't open $file $!";

while ( <FILE> ) {
        chomp;
        if ( $_ = /\d+\*/ ) {
                print "$_\n";
        }
}
[download]

As for the \d{1,} -- I was actually going to put an upper limit on it at one point, so just wrote it that way. For now the + will do though.

Update - I tried on another machine, and it works, so it's definitely machine related. Both machines are running Perl v5.8.0 Cheers

Do you get the same error if you use =~ instead of = ?

From perl581delta:

=head2 UTF-8 On Filehandles No Longer Activated By Locale

In Perl 5.8.0 all filehandles, including the standard filehandles,
were implicitly set to be in Unicode UTF-8 if the locale settings
indicated the use of UTF-8.  This feature caused too many problems,
so the feature was turned off and redesigned: see L</"Core Enhancement
+s">.
[download]

Consider upgrading, or switch to a non-UTF8 locale, or binmode FILE.