-
Notifications
You must be signed in to change notification settings - Fork 559
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unicode and locales #7951
Comments
From [email protected]Created by [email protected]Running this: #!/usr/bin/perl -l for me prints: Commenting out the "use locale", it prints "yes" as expected. (I actually have no locale (LC...) environment varibles set on this machine) Carefully reading the locale comments in perldoc perlunicode doesn't make me Perl Info
|
From [email protected]Perl-5 . 8 . 0 @ Ton . Iguana . Be <perl5-porters@perl.org> writes:
Well no LC* or LANG set implies C locale i.e. 7-bit ASCII
|
The RT System itself - Status changed from 'new' to 'open' |
From [email protected]
well, it behaves exatly the same, even if the locale (LC_ALL) is set |
From [email protected]In article <20050606180637.8966.6@llama.ing-simmons.net>,
No, I don't think its that simple. Just because you have the C locale perl -wle 'use locale; $string = chr(0x10c); print unpack("H*", $string); print unpack("H*", lc($string))' Anyways, the bug also appears if you *DO* set a locale. And also notice that the bug disappears when I add a start of string anchor: #!/usr/bin/perl -l yes Certainly having ^ here shouldn't matter. But it does. |
From @khwilliamsonThis should be fixed in 5.13.10 |
@khwilliamson - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#36118 (status was 'resolved')
Searchable as RT36118$
The text was updated successfully, but these errors were encountered: