On Wed, 30 Jul 2003 at 21:53 (+0200), Michael Matz wrote:

On Wed, 30 Jul 2003, Bernhard Walle wrote:

...

unstable aber natürlich würde mich SuSE 8.2 auch brennend interessieren.

Immer noch futsch.

Was soll das jetzt bedeuten? Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ Als ich klein war, glaubte ich, Geld sei das wichtigste im Leben. Heute, da ich alt bin, weiß ich: Es stimmt. -- Oscar Wilde

Moin, Am Don, 2003-07-31 um 09.57 schrieb Bernhard Walle:

On Wed, 30 Jul 2003 at 22:25 (+0200), Ratti wrote:

...

Am Mit, 2003-07-30 um 21.07 schrieb Bernhard Walle:

...

Debian unstable

Dienstag, März 12, 1995

Also korrekt.

Also in einer utf-8 Umgebung mit einem utf-8 xterm und einem unicode-Font?

Himmel! Bernhard! Was weiss ich? Soviele Fragen! Wo soll ich gucken? :-))) Also mal langsam. Ich verwende ein Debian-unstable, weil ich, wie du auch, mit meiner Software utf8-Probleme in perl habe - genauer gesagt: Die anderen haben. Unter Suse und RedHat. Unter Debian scheint sich das nicht so recht nachvollziehen zu lassen. Alles geht.

#!/bin/sh export LANG=de_DE@euro.utf-8 exec xterm -u8 -fn '-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1'

Ich arbeite normalerweise im Gnome-Terminal. Wenn ich obiges als Script speichere und starte, erhalte ich die Meldung: Warning: locale not supported by C library, locale unchanged In einem neuen Fenster geht ein hässliches xterm auf. Jetzt dein Datumsprogramm vom letzten mal: ./tmp.pl perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = "de_DE@euro.utf-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Tuesday, March 12, 1995 ratti@ratti:~$ echo $LANGUAGE ratti@ratti:~$ echo $LC_ALL ratti@ratti:~$ echo $LANG de_DE@euro.utf-8 Uh. Unter dem gnome-Terminal lief es problemlos: ./tmp.pl Dienstag, März 12, 1995 perl, v5.8.0

Oder arbeitest Du standardmäßig in einer Unicode-Umgebung?

Nein, in Hamburg/St.Pauli, das ist eher Multikulti als Unicode. :-) Ich will dir die Frage gern beantworten, verstehe sie aber nicht. Was soll ich tippen? 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/

Moin, Am Sam, 2003-08-02 um 15.50 schrieb Bernhard Walle:

On Sat, 02 Aug 2003 at 14:39 (+0200), Ratti wrote:

...

Am Don, 2003-07-31 um 09.57 schrieb Bernhard Walle:

...

On Wed, 30 Jul 2003 at 22:25 (+0200), Ratti wrote:

...

Am Mit, 2003-07-30 um 21.07 schrieb Bernhard Walle:

...

Ich verwende ein Debian-unstable, weil ich, wie du auch, mit meiner Software utf8-Probleme in perl habe - genauer gesagt: Die anderen haben. Unter Suse und RedHat. Unter Debian scheint sich das nicht so recht nachvollziehen zu lassen. Alles geht.

Wie ich jetzt von Rene Engelhard (Debian-Entwickler und Maintainer von Muttprint) weiß, verwendet Debian ein gepatchtes Perl 5.8.0, in dem Probleme, die normalerweise erst mit 5.8.1 behoben sind, schon behoben sind (doofer Satz). Insofern kannst Du Dein 5.8.0 nicht unbedingt 1:1 mit dem 5.8.0 von SuSE oder RedHat (welches auch wieder auf eine andere Art gepatcht ist) vergleichen. Soviel dazu.

Aaaah... Verstehe. Siehe dazu "mein" utf8-Thread hier in der Liste. Das heisst im Klartext: Ich kann den Fehler unter Debian unstable weder nachvollziehen noch provozieren, weil er a) rausgeflogen ist und b) gar nicht das Resultat meines schäbigen Programmierstils ist, sondern ein Bug in Perl. Bringt mir Weizenkorn. Viel.

...

...

#!/bin/sh export LANG=de_DE@euro.utf-8 exec xterm -u8 -fn '-misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1'

Ich arbeite normalerweise im Gnome-Terminal. Wenn ich obiges als Script speichere und starte, erhalte ich die Meldung:

Warning: locale not supported by C library, locale unchanged In einem neuen Fenster geht ein hässliches xterm auf. Jetzt dein Datumsprogramm vom letzten mal:

Schaut so aus als ob es die locale auf Deinem Rechner gar nicht gibt. Unter welcher locale arbeitest Du denn standardmäßig? Tippe mal

$ locale

in Deinem heißgeliebten gnome-terminal (*g*) ein. Ansonsten kannst Du mit "dpkg-reconfigure locales" alle möglichen Sprachumgebungen bauen lassen und auch die Standard-locale festlegen.

Jepp, soweit klar, da habe ich aber nicht weiter nachgeguckt, weil ich (Da ich am gleichen Problem bastle) bereits wusste, daß ich utf8 nutze. Erwartungsgemäß sind meine locales m.E. korrekt gesetzt: ratti@ratti:~$ locale LANG=de_DE.UTF-8 LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL= Ich nehme mal eher an, daß deine Notation "falsch" ist. Dein Script setzt ja: export LANG=de_DE@euro.utf-8 was nicht klappt (Weiol xterm dann motzt und mit "C" startet), während alles prima geht, wenn ich LANG auf "de_DE.UTF-8" (ohne Euro) lasse und xterm mit den von dir vorgegebenen Parametern starte. Übrigens kann ich mit deiner "euro"-Notation nicht mal perl starten. Ich fasse zusammen: Dein Script läuft unter dem gnome-Terminal korrekt. Es läuft auch unter dem xterm korrekt. Das einzige, was nicht läuft, ist die Variante mit dem "euro". Mit dr geht gar nix, weder perl noch xterm, geschweige dein Script. Das sollte sich mit einem alias lösen lassen, was ich mir jetzt mal spare, da du ja nur das Test-Resultat wissen wolltest und nicht das Script "zum laufen bringen". Irgendwo (ich glaube, das FAQ zum Debian stable und dort die Sektion zur Euro-Anpassung) habe ich auch gelesen, daß noch viele Programme Probleme mit den aktuellen locales haben, teilweise sogar mit Gross-/Kleinschreibung, und wenn man über sowas stolpert, soll man einen Bug melden.

Den Standardzeichensatz bekommst Du mit "locale charmap" heraus. Nur wenn dort utf-8 steht arbeitest Du in einer Unicode-Umgebung.

Auch das ist bei mir korrekt: ratti@ratti:~$ locale charmap UTF-8

Bei RedHat ist das Standard, deshalb gibt's auch dort so viele Probleme. Andererseits, irgendwann *ist* utf-8 Standard, insofern bin ich froh dass die RedHat-User als Versuchskaninchen zur Verfügung stehen. ;-)

Versuchskaninchen mit roten Hüten. Alice im Linuxland. :-)

Mit dem gnome-terminal kenne ich mich jetzt nicht so gut aus, aber ich denke dass das standardmäßig utf-8 tauglich ist, wenn LANG entsprechend (vor dem Start von gnome-terminal) gesetzt ist.

Ist es.

Ansonsten solltest Du vielleicht "man 7 locale" lesen.

Was prinzipiell immer ein guter Tip ist, in diesem Fall aber nicht nötig, denn auch Debian unstable scheint, wie RedHat, von Haus aus ein "utf8-System" zu sein. Gruß, Ratti P.S.: Bei der Gelegenheit muß ich ja mal loswerden: Was Debian so "unstable" nennt... Ich nutze es jetzt seit einem Monat - es kommen zwar täglich ca. 5-10 MB Updates, aber es läuft echt fast problemfrei. -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/

Moin, Am Sam, 2003-08-02 um 19.34 schrieb Bernhard Walle:

On Sat, 02 Aug 2003 at 19:11 (+0200), Ratti wrote:

...

Am Sam, 2003-08-02 um 15.50 schrieb Bernhard Walle:

...

On Sat, 02 Aug 2003 at 14:39 (+0200), Ratti wrote:

...

Ich nehme mal eher an, daß deine Notation "falsch" ist. Dein Script setzt ja: export LANG=de_DE@euro.utf-8

Nein, die Notation ist richtig. Eine Zeit lang war de_DE mit Mark und de_DE@euro mit Euro, unabhängig vom Währungssymbol. Jetzt scheint aber de_DE auch mit Euro zu sein und das de_DE@euro überflüssig.

Nochmal: Bist Du Dir sicher, dass es die locale "de_DE@euro" bei Dir gibt? Also "dpkg-reconfigure locales" aufrufen und dort schauen ob bei de_DE@euro ein Häkchen (oder Sternchen) ist.

[ ] de_CH.UTF-8 UTF-8 [*] de_DE@euro ISO-8859-15 [*] de_DE ISO-8859-1 [*] de_DE.UTF-8@euro UTF-8 [*] de_DE.UTF-8 UTF-8 [ ] de_LU@euro ISO-8859-15 Ich lasse es bei dieser Gelegenheit aber nochmal durchlaufen. Es ist schliesslich "unstable", da kann sich ja mal was tun. Hmm.... wo kann man jetzt nachgucken, ob es die wirklich gibt? Auf der Suche fand ich einen Ordner "/usr/share/i18n", der wiederum "locales" und "charmap" enthält. Dort existiert "./locales/de_DE@euro" Der obigen Tabelle entnehme ich aber, daß de_DE@euro gar keine UTF8-Codierung ist, sondern eine 8859-15, also eine 8-Bit-Codierung mit Eurozeichen, IIRC. Es gibt also hier kein "de_DE@euro.utf-8", oder? "Korrekt" wäre dann wohl die Variante "de_DE.UTF-8@euro".

...

P.S.: Bei der Gelegenheit muß ich ja mal loswerden: Was Debian so "unstable" nennt... Ich nutze es jetzt seit einem Monat - es kommen zwar täglich ca. 5-10 MB Updates, aber es läuft echt fast problemfrei.

Naja, ab und zu kann es Dir aber passieren dass gar nichts mehr läuft oder C++ Programme nicht mehr starten. Ging mal über die Debian-Liste. Aber im Großen und Ganzen ist es sicherlich brauchbar.

Ich bin überrascht. Was als Bastelsystem zum hantieren mit ut8 gedacht war, ist jetzt mein Alltags-System. Sollte das Teil tatsächlich crashen, boote ich einfach wieder woody, welches dank Backports die gleichen Versionen von Evolution, Mozilla, Firebird,... verwendet, wobei die entsprechenden Mail/Bookmark/Konfig-Ordner per Softlink sowieso die gleichen sind. Damit komme ich prima über die Runden bis das unstable-Problem gefixt ist. :-)

Mein Debian stable + haufenweise Backports + selber installierte "Backports" läuft jedenfalls sehr stabil. Allerdings wird's jetzt schön langsam für ein nächstes 'stable' Zeit, Woody ist ja auch schon über ein Jahr alt.

Ja! :-) 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/

Bernhard Walle [Thu, 31 Jul 2003 09:57:21 +0200]:

export LANG=de_DE@euro.utf-8

Wenn du es schon korrekt machen willst, dann wäre dies: export LANG=de_DE.UTF-8 Wohlgemerkt UTF-8 grossgeschrieben, dann gibt es auch mit den X11 locales keinen Ärger. @euro.utf-8 ist auf jedenfall unsinnig, auch wenn es offensichtlich in /usr/share/locale/alias vermerkt zu sein scheint. Philipp

Hi, On Thu, 31 Jul 2003 at 01:25 (+0200), Ratti wrote:

Am Mit, 2003-07-30 um 23.52 schrieb Christian Boltz:

...

...

Es scheint also als wäre der String "doppelt" utf-8 kodiert!

Ja :-(

Bei den Fontlingen plagt sich Ratti gerade mit einem ähnlichen Problem rum. Mit "use bytes; no utf8;" hat er schon die Fehlermeldungen losbekommen [1], aber die Ausgabe bringt immer noch die uft8-Doppelbytes (aber immerhin nur einmal codiert ;-)

Falls Du eine Lösung findest, lass es mich wissen ;-)

use bytes; hat mich weitergebracht, wenn auch nicht ans Ziel. no utf8 kann man vergessen, das besagt lediglich, das der perl-Quelltext nicht utf8-codiert ist.

bringt mich hier auch nicht weiter.

...

[1] die kamen übrigens daher, dass Binärdaten (!) in einer RegEx verarbeitet werden und Perl dann "halbe" utf8-Bytes gemeldet hat ;-)

Schwieriges Thema. Sehr schwieriges Thema. Da muß echt mal jemand ein HowTo schreiben.

Oder so implementieren, dass es ohne Howto geht. ;-) Mein Vorschlag wäre, dass Perl intern Strings *immer* als Unicode behandelt und bei der Ein-/Ausgabe entsprechend der aktuellen locale konvertiert. Ähnlich wie es unter Java gemacht wird. Dazu bräuchte man dann aber grundlegende Unterscheidung zwischen Zeichen-I/O und Byte-I/O. utf-8 wäre was für Perl 6 gewesen, stattdessen hat man es notdürftig in Perl 5.6 implementiert und in 5.8 verschlimmbessert und die Programmierer dürfen sich damit dumplagen.

Da hat man eine ordentliche Zeichenkette, in der halt ein CHR(190) vorkommt, und plötzlich fängt perl an, Zweibyte-Characters zu basteln. Kann man mit "use bytes" abstellen, und plötzlich sind die ganz normalen einByte-Umlaute wech. Stöhn. Gibt es VisualBasic für Linux? :-)

Nein, gibt es nicht. Vielleicht wäre Python noch was, soll ja auch eine sehr gute (objektorientierte) Skriptsprache sein. OO in Perl kann man meiner Meinung nach sowieso vergessen. Wenn nicht noch ein Wunder passiert wird das hier ein "Known bug". Ich programmiere nicht um Bugs in Perl in dieser Art herum, weil es weder zu Perl 5.6 noch zu Perl 5.8.x (mit behobenem Bug) kompatibel wäre. Dann muss der Anwender halt auf formatierte Datumsangaben in einer Unicode- Locale verzichten. @Ratti: Machen wir einen Club "utf-8 geplagte Perl-Programmierer" auf? Gruß, Bernhard -- "Does your computer ever crash?" "Oh definitely, believe me. We want to make a tool that we can use ourselves and we know from our own use we can make it a lot better and a lot more reliable." -- Bill Gates in a BBC interview

On Sat, 02 Aug 2003 at 19:38 (+0200), Ratti wrote:

Am Don, 2003-07-31 um 10.40 schrieb Bernhard Walle:

...

On Thu, 31 Jul 2003 at 01:25 (+0200), Ratti wrote:

...

Am Mit, 2003-07-30 um 23.52 schrieb Christian Boltz:

...

...

use bytes; hat mich weitergebracht, wenn auch nicht ans Ziel. no utf8 kann man vergessen, das besagt lediglich, das der perl-Quelltext nicht utf8-codiert ist.

bringt mich hier auch nicht weiter.

Nein, aber in der "use bytes;"-Ecke treibt sich noch mehr Doku rum, da muß man mal'n paar Links hinterherlaufen.

Recht interessant ist: http://www.perldoc.com/perl5.8.0/pod/perlguts.html#Unicode-Support http://www.perldoc.com/perl5.8.0/pod/perlunicode.html

Eventuell noch: http://www.perldoc.com/perl5.8.0/lib/Encode.html

Naja, ich habe die Probleme mittlerweile alle (bis auf drei, die aber auf Bugs in Perl beruhen und entsprechend dokumentiert sind) gelöst.

...

Mein Vorschlag wäre, dass Perl intern Strings *immer* als Unicode behandelt und bei der Ein-/Ausgabe entsprechend der aktuellen locale konvertiert.

Damit kann dann wieder ich nix anfangen. Ich habe Binärdateien (PS-Fonts), die klassisches 8-Bit ASCII enthalten.

Ich kann nix damit anfangen, daß sich ganze Programmsegmente als "use bytes" deklarieren lassen, noch kann ich brauchen, daß da irgendwas als 16-Bit interpretiert wird. Ich bräuchte vielmehr eine Unterscheidung zwischen ASCII und Unicode-Skalaren. Sobald ich in meinem Binärkram die Ascii-Daten rausgefummelt habe, dürfen sie ja gerne nach Unicode konvertiert werden - aber erst dann. Vorher stolpere ich über Binärschrott, der nunmal 192 60 enthalten kann.

Man muss halt zwischen Text und Bytes konsequent unterscheiden, wie dies beispielsweise in Java gelöst ist (da gibt es beispielsweise FileReader zum Einlesen von Zeichenketten und FileInputStream zum Einlesen von Bytes). Aber ich sehe schon, ich ändere die komplette Architektur von Perl. Naja, mir sind halt getypte Programmiersprachen wie C/C++ oder Java lieber. Perl hat zwar durchaus seine Stärken in der Textverarbeitung, aber als allgemeine Programmiersprache bevorzuge ich dann was anderes. Für Muttprint ist es aber sehr gut geeignet, deshalb habe ich es ja auch verwendet und mich damit rumgeärgert. ;-)

...

Wenn nicht noch ein Wunder passiert wird das hier ein "Known bug". Ich programmiere nicht um Bugs in Perl in dieser Art herum, weil es weder zu Perl 5.6 noch zu Perl 5.8.x (mit behobenem Bug) kompatibel wäre. Dann muss der Anwender halt auf formatierte Datumsangaben in einer Unicode- Locale verzichten.

Eventuell könnte man den ja catchen. Du hast es ja einfach, es betrifft nur das Datum. Man könnte ja mit einer gezielten Streingoperation gucken, ob das Resultat 5.6 / 5.8.1 -kompatibel ist, oder 5.8.bug. Je nachdem kannst du nochmal "entcoden", siehe einer der Links da oben.

Ehrlich gesagt ist mir das zu blöd. Als nächstes programmiere ich dann um einen Bug in der Hardware herum. Der Bug ist dokumentiert, es gibt drei Möglichkeiten für den User: * Perl updaten * keine UTF-8 Umgebung verwenden (was die meisten Leute sowieso nicht machen) * DATE=original, wodurch das Datum nicht in die Landessprache übersetzt wird sondern wie in der Mail angegeben ausgedruckt wird Soll er sich irgendwas aussuchen.

...

@Ratti: Machen wir einen Club "utf-8 geplagte Perl-Programmierer" auf?

Auch 'ne Alternative. Ich habe mir eigentlich überlegt, mir im Keller einen schalldichten Anspruchshaltungsraum(TM) zu bauen, in dem ich aufblasbare Imitationen von Freie-Software-Programmierern anbrülle, was ich alles fordere, und bis wann. Und daß sie mich beschissen haben. Und daß ich mein Geld zurückwill. Und ihren Vorgesetzten sprechen. SOFORT. :-)

*g* Naja, eigentlich habe ich auch was gegen Anspruchshaltung, aber Unicode wäre meines Erachtens was für Perl 6 gewesen, was man dadurch beschleunigt hätte und nicht in Perl 5 notdürtig mit haufenweise Bugs reinschustern. Just my 2 ¢. Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ "Software is like sex, it's better when it's free." -- Linus Torvalds