perl5.8, utf8, unterschiedliche Distris
Hallo, Ich habe ein Problem mit perl und utf8. Ich habe in perl ein Script geschrieben, welches sich binären Krempel in Variablen liest und darin rumliest, indem es Stringfunktionen verwendet. Zum Beispiel: ord(substr($file,$adr,1)), um einen Byte-wert auszulesen. (Ich weiss, das ist dirty, aber lasst uns Stildiskussionen jetzt mal beiseite schieben. Ich brauche gerad mal einen schnelle Lösung, schön mache ich später.) Unter perl 5.6.x ging das völlig problemlos. Jetzt habe ich Reports von Suse- und RedHat-Usern bekommen, die eindeutig darauf zurückzuführen sind, daß ihr perl 5.8 die binären Daten als UTF interpretiert und es daraufhin Folgefehler hagelt. Ich habe mir daraufhin ein Debian unstable installiert, aber Pustekuchen: Das hat zwar auch perl 5.8, aber alles läuft völlig problemlos! Mit ein bisschen ins-Blaue-schiessen habe ich herausgefunden, daß es bei den Suse/RH-Leuten so ungefähr wieder läuft, wenn ich use bytes; setze. (Zwar wird bei Ausgaben auf die Kommandozeile statt Sonderzeichen der typische zwei-Zeichen-Blödsinn ausgegeben, wenn ein Programm halt nicht mit utf-Daten umgehen kann, aber das ist jetzt erstmal egal. Der technische Teil läuft.) Da ich das Problem gerne gezielt fixen möchte durch setzen von use bytes und no bytes, möchte ich das "bad behavior" auf meinem Debian reproduzieren. Klartext: Ich suche einen Weg, daß es auf Debian auch nicht funktioniert! Ich habe daher versucht, no bytes; use utf8; zu setzen, aber Debian lässt sich nicht davon abbringen, alles fehlerlos auszuführen, was ausnahmsweise mal ein Problem ist. Was ist bei Suse und RedHat anders? Wie kann ich Debian auf deren Verhalten umswitchen? Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Am Mit, 2003-07-16 um 21.40 schrieb Joerg Rossdeutscher:
Hallo,
Ich habe ein Problem mit perl und utf8. [...]
Wenn du in dieser Liste keine Hilfe bekommst, wende dich doch an die Newsgroups von Perl. Da ist die Chance höher im der Kreis der angesprochenen einen zu finden, der dir helfen kann. Mathias
On Wed, 2003-07-16 at 21:40, Joerg Rossdeutscher wrote:
Da ich das Problem gerne gezielt fixen möchte durch setzen von use bytes und no bytes, möchte ich das "bad behavior" auf meinem Debian reproduzieren.
Klartext: Ich suche einen Weg, daß es auf Debian auch nicht funktioniert!
Was ist bei Suse und RedHat anders? Wie kann ich Debian auf deren Verhalten umswitchen?
Evt. kompiliert Debian perl5.8 anders. Versuch es doch mal mit einem selbstkompilierten Perl. (Oder lass einen der User, die die Fehler gemeldet haben, Dir ein perl -V zusenden. Dann kannst Du das mit Deinem Perl vergleichen. Ich arbeite zwar mit einem SuSE System, habe mein Perl aber selbst kompiliert, so daß ich Dir da nicht helfen kann.) Gruß Volker
On Fri, 18 Jul 2003 at 09:21 (+0200), Volker Kroll wrote:
On Wed, 2003-07-16 at 21:40, Joerg Rossdeutscher wrote:
Da ich das Problem gerne gezielt fixen möchte durch setzen von use bytes und no bytes, möchte ich das "bad behavior" auf meinem Debian reproduzieren.
Klartext: Ich suche einen Weg, daß es auf Debian auch nicht funktioniert!
Was ist bei Suse und RedHat anders? Wie kann ich Debian auf deren Verhalten umswitchen?
Evt. kompiliert Debian perl5.8 anders. Versuch es doch mal mit einem selbstkompilierten Perl. (Oder lass einen der User, die die Fehler gemeldet haben, Dir ein perl -V zusenden. Dann kannst Du das mit Deinem Perl vergleichen. Ich arbeite zwar mit einem SuSE System, habe mein Perl aber selbst kompiliert, so daß ich Dir da nicht helfen kann.)
Mein Perl von SuSE 8.1 (ist ja noch auf der Platte :-)): [/] # perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.19, archname=i586-linux-thread-multi uname='linux bloembergen 2.4.19 #1 mon apr 15 08:57:26 gmt 2002 i686 unknown ' config_args='-ds -e -Dprefix=/usr -Dusethreads -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=true' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3 --pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing' ccversion='', gccversion='3.2', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags ='' libpth=/lib /usr/lib /usr/local/lib libs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i586-linux-thread-multi/CORE' cccdlflags='-fPIC', lddlflags='-shared' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Sep 9 2002 18:13:56 @INC: /usr/lib/perl5/5.8.0/i586-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i586-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ I'm telling you that the kernel is stable not because it's a kernel, but because I refuse to listen to arguments like this. -- Linus Torvalds
On Fri, 2003-07-18 at 09:30, Bernhard Walle wrote:
On Fri, 18 Jul 2003 at 09:21 (+0200), Volker Kroll wrote:
Evt. kompiliert Debian perl5.8 anders. Versuch es doch mal mit einem selbstkompilierten Perl. (Oder lass einen der User, die die Fehler gemeldet haben, Dir ein perl -V zusenden. Dann kannst Du das mit Deinem Perl vergleichen. Ich arbeite zwar mit einem SuSE System, habe mein Perl aber selbst kompiliert, so daß ich Dir da nicht helfen kann.)
Mein Perl von SuSE 8.1 (ist ja noch auf der Platte :-)):
[/] # perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3 --pipe', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing' ccversion='', gccversion='3.2', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define
So sieht es bei meinem Perl aus. Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.3 20010315 (SuSE)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Ich vermute mal, daß es am gcc liegt. Wenn Du mir das Prog schicken willst, kann ich es gern mal mit meinem Perl versuchen. Gruß Volker
Moin,
On Fri, 18 Jul 2003 at 09:21 (+0200), Volker Kroll wrote: Mein Perl von SuSE 8.1 (ist ja noch auf der Platte :-)):
[/] # perl -V
Uuh. Danke erstmal für eure Hilfe. Ich sehe leider nicht, wie man da jetzt weiterkäme... Es scheint sich ja nicht um einen Bug zu handeln, sondern um eine Konfiguration. Und in euren Outputs von "perl -V" sehe ich so gar nix, was irgendwie mit utf8, Datenbreite eines Zeichens oder so zu tun hätte. Ich muß allerdings dazu sagen, daß ich nicht übermässig fit in perl bin. :-) Ich würde mal einen anderen Ansatz pflegen: Wenn ich unter Suse8.2 ein "use bytes;" an den Anfang stellen lasse, dann geht vieles plötzlich. Debian scheint von vornherein auf "use bytes" eingestellt zu sein, während das perl von Suse und RH defaultmässig mit "no bytes;" startet. Gibt es nicht einen Befehl, der anzeigt, was da gerade ge"use"t und ge"no"t wird? Sozusagen das perl-Enviroment angucken? Gaaah! Da fällt mir ein, ich habe euch eine ganz wichtige Sache nicht erzählt: Durch setzen von $LANG auf eine nicht-utf8-Umgebung lässt sich das Problem lösen! Ich will aber, daß es auch unter UTF-8 läuft. Sorry! Nichtsdestotrotz: Ich stelle mal das perl -V von meinem Debian dazu, vielleicht seid ihr ja heller als ich. Allerdings wären das dann _vermutlich_ alles Versionen, auf denen ich das Problem nicht habe, es scheint begrenzt zu sein auf die allerneuesten Distris. Wenn hier jemand Suse 8.2 einsetzt UND(!) $LANG auf irgendwas.UTF8 stehen hat, könnte derjenige vielelicht die Ausgabe von perl -V dazustellen? Danke! Hier meins: ratti@ratti:~$ perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.20-xfs+ti1211, archname=i386-linux-thread-multi uname='linux kosh 2.4.20-xfs+ti1211 #1 sat nov 30 19:19:08 est 2002 i686 gnulinux ' config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr -Dprivlib=/usr/share/perl/5.8.0 -Darchlib=/usr/lib/perl/5.8.0 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.0 -Dsitearch=/usr/local/lib/perl/5.8.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib -Dlibperl=libperl.so.5.8.0 -Dd_dosuid -des' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3', cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing' ccversion='', gccversion='3.3 (Debian)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt perllibs=-ldl -lm -lpthread -lc -lcrypt libc=/lib/libc-2.3.1.so, so=so, useshrplib=true, libperl=libperl.so.5.8.0 gnulibc_version='2.3.1' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under linux Compiled at Jun 5 2003 23:33:07 @INC: /etc/perl /usr/local/lib/perl/5.8.0 /usr/local/share/perl/5.8.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8.0 /usr/share/perl/5.8.0 /usr/local/lib/site_perl . Vielen Dank, Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Hello, On Fri, 18 Jul 2003, Joerg Rossdeutscher wrote:
Nichtsdestotrotz: Ich stelle mal das perl -V von meinem Debian dazu, vielleicht seid ihr ja heller als ich. Allerdings wären das dann _vermutlich_ alles Versionen, auf denen ich das Problem nicht habe, es scheint begrenzt zu sein auf die allerneuesten Distris. Wenn hier jemand Suse 8.2 einsetzt UND(!) $LANG auf irgendwas.UTF8 stehen hat, könnte derjenige vielelicht die Ausgabe von perl -V dazustellen? Danke!
Kann ich mal mit SuSE 8.2 und nem verkorksten Woody testen... Achso, 'perl -V' ist eher weniger aussagekraeftig. 1. Hast du mal was, was mit LANG="foo" (foo !~ /\.UTF.*/), funktioniert und mit LANG="*.UTF*" nicht? So dass wir konkret testen koennen? 2. Aussagekraeftig bzgl. der perl-config ist die Ausgabe von: perl -MConfig -e 'print Config::config_sh();' Mein (etwas defektes) perl hat z.B. u.a.: ivtype='long long' nvtype='long double' 3. ich habe den leisen Verdacht, dass es evtl. eher mit den Unicode::* Modulen zusammenhaengen koennte, denn perl selbst kann AFAIK kein Unicode/UTF*. Interessant koennte z.B. die Ausgabe von $ echo 'i Unicode::MapUTF8' | perl -MCPAN -e'shell' | grep VERSION CPAN_VERSION 1.09 INST_VERSION 1.09 sein. Auch noch die Versionen von anderen Modulen koennten interessant werden... (Unicode::Normalize z.B.) $ echo 'i utf8' | perl -MCPAN -e'shell' | grep VERSION CPAN_VERSION 1.00 INST_VERSION 1.00 -dnh -- SIG kill(ed)
Moin, Am Fre, 2003-07-18 um 22.31 schrieb David Haller:
On Fri, 18 Jul 2003, Joerg Rossdeutscher wrote:
Nichtsdestotrotz: Ich stelle mal das perl -V von meinem Debian dazu, vielleicht seid ihr ja heller als ich. Allerdings wären das dann _vermutlich_ alles Versionen, auf denen ich das Problem nicht habe, es scheint begrenzt zu sein auf die allerneuesten Distris. Wenn hier jemand Suse 8.2 einsetzt UND(!) $LANG auf irgendwas.UTF8 stehen hat, könnte derjenige vielelicht die Ausgabe von perl -V dazustellen? Danke!
Kann ich mal mit SuSE 8.2 und nem verkorksten Woody testen...
Achso, 'perl -V' ist eher weniger aussagekraeftig.
Sah für mich auch so aus.
1. Hast du mal was, was mit LANG="foo" (foo !~ /\.UTF.*/), funktioniert und mit LANG="*.UTF*" nicht? So dass wir konkret testen koennen?
Leider nicht - das ist das Problem: Hier geht alles. Wie gesagt, ich würde ja gerne mein perl so konfigurieren, daß es hier _nicht_ mehr geht, damit ich den Code schrubben kann, damit er wiederum überall funktioniert. Mein Eindruck ist der folgende: Ich lade sagenwirmal 5 Bytes binäre Daten in einen Skalar. Das enthält dann sowas: ".a_cb Um den binären Wert des Zeichens an der vierten Stelle rauszukriegen, habe ich sowas gemacht: print ord(substr($data,3,1)); Ergibt den Bytewert von "c". Es scheint aber so zu sein, daß, wenn perl auf utf8 voreingestellt ist UND zufälligerweise "a_" einen utf8-Code darstellt, daß diese beiden Zeichen dann als eines gezählt werden und der Zugriff auf das vierte Zeichen dann "b" erwischt. Natürlich basiert das ganze Problem darauf, daß ich in meinem jugendlichen Leichtsinn mit Textfunktionen auf binäre Daten losgehe. Ich kanns halt nicht besser. Kann man perl irgendwie verklüsen, daß eine Variable kein "Text" ist sondern ein "Array of Bytes", sprich: Ohne Encoding ist? Ich habe sowas wie oben inzwischen auf "unpack" umgestellt, mangels Problemen kann ich nicht sagen, ob es besser läuft.
2. Aussagekraeftig bzgl. der perl-config ist die Ausgabe von:
perl -MConfig -e 'print Config::config_sh();'
Himmel! Hölle! Mehr nicht? Das kann ich aber hier nicht posten... %-) Ich habe aber mal etwas rumgegrept ("utf", "char" , "byte",...) und sowas gefunden: i8type='char' netdb_name_type='const char *' stdchar='char' u8type='unsigned char'
Mein (etwas defektes) perl hat z.B. u.a.: ivtype='long long' nvtype='long double'
ivtype='long' nvtype='double'
3. ich habe den leisen Verdacht, dass es evtl. eher mit den Unicode::* Modulen zusammenhaengen koennte, denn perl selbst kann AFAIK kein Unicode/UTF*. Interessant koennte z.B. die Ausgabe von
$ echo 'i Unicode::MapUTF8' | perl -MCPAN -e'shell' | grep VERSION CPAN_VERSION 1.09 INST_VERSION 1.09
Da das Programm mit binären Daten jongliert, habe ich eigentlich gar keine Unicode-Sachen eingebettet. Brauche ich ja nicht. Obiges Kommando ergibt bei mir nur eine leere Zeile... Igitt, ach so, geht nur als root, und der grep verspeist diese Warnung. OK. Also: CPAN_VERSION 1.09
sein. Auch noch die Versionen von anderen Modulen koennten interessant werden... (Unicode::Normalize z.B.)
$ echo 'i utf8' | perl -MCPAN -e'shell' | grep VERSION CPAN_VERSION 1.00 INST_VERSION 1.00
CPAN_VERSION 1.00 INST_VERSION 1.00 Hmm... Ich finde den Ansatz oben mit der "Config" interessant, da wird's wohl liegen. Ist das irgendwo dokumentiert? Der Kram unter http://theoryx5.uwinnipeg.ca/mod_perl/cpan-search?new=Search;site=ftp.funet.... scheint alles nicht zu passen. Seufz. Ich glaube, ich muß den Suse-8.2-Karton aufmachen. :-) Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Hi, On 19 Jul 2003, Joerg Rossdeutscher wrote:
Ich lade sagenwirmal 5 Bytes binäre Daten in einen Skalar. Das enthält
print ord(substr($data,3,1));
Yep, das wird so nicht gehen, da encoding abhaengig. Leider weiss ich nicht, ob das encoding "im String" gespeichert ist (dann wuerde man ihn wohl einfach in einen Bytestring umwandeln koennen, und substr() wuerde wieder gehen), oder global aus dem Environment genommen wird, jedesmal wenn substr() aufgerufen wird. Ich fuerchte letzteres, das ist logischer. Und in dem Fall kannst du substr nicht benutzen (jedenfalls nicht ohne LANG umzuschalten).
kanns halt nicht besser. Kann man perl irgendwie verklüsen, daß eine Variable kein "Text" ist sondern ein "Array of Bytes", sprich: Ohne Encoding ist?
Nicht das ich wuesste. Ein Skalar hat nur drei Sybtypen: Referenz, Zahl oder String. Das einzige was mir da mit Perl-Hausmitteln einfaellt ist: @as_bytes = unpack ("c*", $input_string); Dein Byte stuende dann an $as_bytes[3].
Ich habe sowas wie oben inzwischen auf "unpack" umgestellt,
Ahh, hmm ;) Ciao, Micha.
Moin, Am Mon, 2003-07-21 um 05.24 schrieb Michael Matz:
Nicht das ich wuesste. Ein Skalar hat nur drei Sybtypen: Referenz, Zahl oder String. Das einzige was mir da mit Perl-Hausmitteln einfaellt ist:
@as_bytes = unpack ("c*", $input_string);
Dein Byte stuende dann an $as_bytes[3].
Ich habe sowas wie oben inzwischen auf "unpack" umgestellt,
Ahh, hmm ;)
:-) So kanns gehen. :-) "unpack" ist also binär, ohne encoding? Gut. Dann läuft es jetzt hoffentlich. Hach, es ist wirklich 'ne Pest, wenn's bei einem selber läuft und man findet das Problem der anderen nicht... %-) Vielen Dank für den Tip. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
participants (6)
-
Bernhard Walle -
David Haller -
Joerg Rossdeutscher -
Mathias-H. Weber -
Michael Matz -
Volker Kroll