Problem mit Umlauten (mal wieder)
Martin Kißner
ich habe den Umgang mit Umlauten in der Shell (hier Z-Shell, s.u.) immer
noch nicht richtig verstanden.
zsh --version
zsh 4.3.9 (i386-apple-darwin9.6.0)
Aktuelle Problem:
Wildcard- und Tab-Vervollständigung funktionieren nicht richtig:
martin% ls -l
total 0
-rw-r--r-- 1 martin staff 0 6 Jan 13:35 Lösung
martin% echo L*
Lösung
martin% echo *ö*
zsh: no matches found: *ö*
Ist das Einstellungssache oder lässt sich das grundsätzlich nicht
beheben.
Was mir noch aufgefallen ist:
Wenn ich 'echo L' + TAB eingebe, wird vervollständigt.
Wenn ich 'echo Lö' + TAB eingebe, wird nicht vervollständigt.
Wenn ich allerdings 'echo L' + TAB eingebe, und nach der
Vervollständigung bis zum s rückwärts lösche (es steht jetzt also 'echo
Lö' in der Kommandozeile), und dann die TAB Taste
erneut drücke, dann wird vervollständigt.
Das Problem scheint mit den "multibyte" characters zu tun zu haben. Ich
weiß aber nicht, wie sich das lösen lässt und bitte um Hilfe und
Erläuterung
Danke und Gruß
Martin
Sven Mascheck
> zsh --version
> zsh 4.3.9 (i386-apple-darwin9.6.0)
>
> martin% echo L*
> L�sung
>
> martin% echo *�*
> zsh: no matches found: *�*
>
> Ist das Einstellungssache oder l�sst sich das grunds�tzlich nicht
> beheben.
Um ein wenig vom jeweils speziellen Fall wegzugehen,
also um es grunds�tzlich besser zu verstehen: Hier
kommen leicht mehrere Faktoren ins Spiel:
- was ist �berhaupt die konfigurierte "locale"
- ist auch das Ein-/Ausgabeger�t (z.B. Terminalemulator, Fonts)
darauf vorbereitet
- kann auch die Anwendung mit dieser locale umgehen
(davon w�rde ich bei einer nicht zu alten zsh ausgehen)
Ein besseres Bild bekommt man hier mit
$ locale # momentan konfigurierter Wert
$ locale -a # tats�chlich verf�gbare Werte
$ ls L*|od -a; echo �|od -a # single- oder multibyte bei Ein/Ausgabe?
Michael Baeuerle
>
> Das Problem scheint mit den "multibyte" characters zu tun zu haben. Ich
> weiß aber nicht, wie sich das lösen lässt und bitte um Hilfe und
> Erläuterung
Moeglicherweise ein Unicode Problem, ein "ö" kann da verschieden codiert
sein. In MacOS X werden Dateinamen z.B. als decomposed UTF-8
verarbeitet.
Spekulation: Die Shell nimmt aber die Zeichen von der Tastatur z.B. als
precomposed UTF-8 und dein eingegebenes "ö" (2 Byte) ist dann nicht das
gleiche "ö" wie im Dateinamen (3 Byte) und das Pattern passt nicht.
Laesst du dagegen vervollstaendigen, nimmt er das "ö" aus dem Dateinamen
und das Pattern passt.
Umlaute in Dateinamen sind mit Unicode ein noch groesseres Problem als
ohne. Vor allem subtiler weil es viele verschiedene Zeichen gibt die
gleich aussehen und sogar verschiedene Codierungen die das gleiche
Zeichen darstellen. Je nach OS und FS kannst du deswegen mit
Unicode-Namen sogar zwei verschiedene Dateien mit dem Namen "Lösung" im
gleichen Verzeichnis liegen haben.
Ich prophezeihe dir:
Wenn du non-ASCII Zeichen in Dateinamen nicht vermeidest wird das "mal
wieder" im Subject nicht das letzte Mal gewesen sein. In heterogenen
Umgebungen frueher, ansonsten halt spaeter ... aber es holt dich ganz
sicher irgendwann wieder ein.
Micha
--
Sehe ich genauso. Wenn man eine Power-Workstation will, nimmt man was
mit Operons und kann dann immer noch zwischen Windoze und diversen
Linux/BSD Varianten waehlen. Oder Solaris (wenn man die Schmerzen eines
kommerziellen UN*X beibehalten moechte). Quelle unbekannt
Martin Kißner
>
> Ich prophezeihe dir:
> Wenn du non-ASCII Zeichen in Dateinamen nicht vermeidest wird das "mal
> wieder" im Subject nicht das letzte Mal gewesen sein. In heterogenen
> Umgebungen frueher, ansonsten halt spaeter ... aber es holt dich ganz
> sicher irgendwann wieder ein.
Da bin ich ganz Deiner Meinung.
Wo ich selbst die Vergabe der Dateinamen bestimme, kann ich das ja
steuern. Man hat aber auch mit Dateien zu arbeiten, die von Cds, aus dem
internet, aus Emails oder sonstwoher kommen.
Schlimmer noch. Ich muss mich in Umgebungen bewegen, in denen man
gewissen Personen auch nach Jahren nicht begreiflich machen kann, dass
' ++ Vergrößerungsstrategie ++ neue Version vom *23.11.2009*'
kein super Dateiname ist. Da wird z.Tl. noch nicht mal vor newline im
Dateinamen zurück geschreckt.
Trotzdem Danke Dir für Deinen Kommentar.
Gruß
Martin
--
perl -e '$S=[[73,116,114,115,31,96],[108,109,114,102,99,112],
[29,77,98,111,105,29],[100,93,95,103,97,110]];
for(0..3){for$s(0..5){print(chr($S->[$_]->[$s]+$_+1))}}'
Martin Kißner
> Martin Kißner wrote:
>
>> zsh --version
>> zsh 4.3.9 (i386-apple-darwin9.6.0)
>>
>> martin% echo L*
>>
>> martin% echo *ö*
>> zsh: no matches found: *ö*
>>
>> Ist das Einstellungssache oder lässt sich das grundsätzlich nicht
>> beheben.
>
locale
LANG="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_CTYPE="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_ALL=
> - ist auch das Ein-/Ausgabegerät (z.B. Terminalemulator, Fonts)
> darauf vorbereitet
nun ja, ich verwende xterm-16color
kann das ein Proplem sein?
> - kann auch die Anwendung mit dieser locale umgehen
> (davon würde ich bei einer nicht zu alten zsh ausgehen)
>
>
> Ein besseres Bild bekommt man hier mit
>
> $ locale # momentan konfigurierter Wert
s. o.
> $ locale -a # tatsächlich verfügbare Werte
da ist "de_DE.UTF-8" jedenfalls dabei
> $ ls L*|od -a; echo ö|od -a # single- oder multibyte bei Ein/Ausgabe?
ls L*|od -a
0000000 L o ? 88 s u n g nl
0000011
echo Lösung | od -a
0000000 L ? ? s u n g nl
0000010
Okay, ich sehe, das hier beim Umlaut nicht die gleiche Ausgabe kommt.
Was sagt mir das aber jetzt _genau_?
Mit od kenne ich mich kaum aus.
Danke und Gruß
Sven Mascheck
> locale
> LANG="de_DE.UTF-8"
> LC_COLLATE="de_DE.UTF-8"
> LC_CTYPE="de_DE.UTF-8"
> LC_MESSAGES="de_DE.UTF-8"
> LC_MONETARY="de_DE.UTF-8"
> LC_NUMERIC="de_DE.UTF-8"
> LC_TIME="de_DE.UTF-8"
> LC_ALL=
Nur am Rande: Enth�lt auch die Ausgabe f�r LANG wirklich double quotes?
Ich kenne das (normalerweise undokumentierte) Verhalten, da� auf diese Weise
illustriert wird, welche Kategorien implizit bzw. explizit gesetzt wurden.
(Darwin ist doch von FreeBSD abgeleitet und zumindest auch ein FreeBSD7.1,
eben zur Hand, verh�lt sich so.)
>> - ist auch das Ein-/Ausgabeger�t (z.B. Terminalemulator, Fonts)
>> darauf vorbereitet
> ich verwende xterm-16color
Da eingetippte Umlaute korrekt ausgegeben werden,
k�nnte hier alles o.k. sein.
>> $ locale -a # tats�chlich verf�gbare Werte
> da ist "de_DE.UTF-8" jedenfalls dabei
Das reicht aus.
> echo L�sung | od -a
> 0000000 L ? ? s u n g nl
Das k�nnte eine g�ltige Kodierung sein.
> ls L*|od -a
> 0000000 L o ? 88 s u n g nl
"od -c" oder "-b" w�re wahrscheinlich g�nstiger gewesen.
Experimentiere mal damit mit einem Auge auf der Manpage.
Ziel ist, die tats�chlich verwendeten Bytes zu erkennen.
Ich habe aber schon Implementationen gesehen, die das
8. Bit abschneiden, auch deshalb w�re -b oder -c besser.
(Und auf "88" kann ich mir bei -a keinen Reim machen,
ohne Deine Implementation genauer anzusehen.)
Eine m�gliche Erkl�rung: Die Datei wurde nicht unter denselben
Bedingungen erstellt, der Name ist "kaputt" und er wird im Terminal
- eher zuf�llig - scheinbar korrekt angezeigt.
Hast Du denn schonmal "touch L�sung2; ls" probiert?
Probiere das sicherheitshalber auch noch in einer anderen
Shell, wie ksh, bash oder (t)csh, die m.W. bei MacOSX an Bord sind.
Martin Kißner
>> echo Lösung | od -a
>> 0000000 L ? ? s u n g nl
>
> Das könnte eine gültige Kodierung sein.
>
>> ls L*|od -a
>> 0000000 L o ? 88 s u n g nl
>
> "od -c" oder "-b" wäre wahrscheinlich günstiger gewesen.
> Experimentiere mal damit mit einem Auge auf der Manpage.
> Ziel ist, die tatsächlich verwendeten Bytes zu erkennen.
> Ich habe aber schon Implementationen gesehen, die das
> 8. Bit abschneiden, auch deshalb wäre -b oder -c besser.
> (Und auf "88" kann ich mir bei -a keinen Reim machen,
> ohne Deine Implementation genauer anzusehen.)
>
> Eine mögliche Erklärung: Die Datei wurde nicht unter denselben
> Bedingungen erstellt, der Name ist "kaputt" und er wird im Terminal
> - eher zufällig - scheinbar korrekt angezeigt.
Es geht nicht um eine einzelne Datei. Das ist ein generelles Problem:
Schau mal:
% touch Lösung
% rm Lö*
zsh: no matches found: Lö*
% echo L* | od -c
0000000 L o ̈ ** s u n g \n
0000011
% echo Lösung | od -c
0000000 L ö ** s u n g \n
0000010
aber:
% echo L<TAB>ösung| od -c
0000000 L o ̈ ** s u n g \n
0000011
Ich kapier das nicht.
Ich tippe den Umlaut immer in der selben Shell ein.
mal ist es 'o ̈ **', mal 'ö **'.
> Hast Du denn schonmal "touch Lösung2; ls" probiert?
> Probiere das sicherheitshalber auch noch in einer anderen
> Shell, wie ksh, bash oder (t)csh, die m.W. bei MacOSX an Bord sind.
In anderen Shells ist das genau so.
Ratlose Grüße
Sven Mascheck
> % echo L* | od -c
> 0000000 L o ? ** s u n g \n
Auf die Darstellung mit doppelten Zeichen (** oder 88) kann
ich mir immer noch keinen Reim machen.
�brigens: Da es ja auch noch via Usenet Darstellungsprobleme
geben k�nnte, ist od -b letztendlich wohl das sicherste.
man ascii ist dann hilfreich.
> % echo L�sung | od -c
> 0000000 L � ** s u n g \n
Das ist ein sehr direkter Hinweis: Bei Unicode d�rfte
hier kein Singlebyte-Umlaut entstehen. Vielleicht
ist Dein xterm doch das Problem. Teste das alles
mal (zum Beispiel) mit "uxterm", das es lt. manpages
auch auf MacOSX gibt.
Juergen P. Meier
> % touch Lï¿œsung
> % rm Lￜ*
> zsh: no matches found: Lￜ*
Drei fragen:
Was sagt "locale"?
Was fuer ein Dateisystem ist das mit welchen Flags "mount"?
Welche 8-bit Einstellungen hat deine zsh?
> % echo L* | od -c
> 0000000 L o ? ** s u n g \n
> 0000011
Das ist wohl UTF-8 kodiert.
> % echo Lï¿œsung | od -c
> 0000000 L ￜ ** s u n g \n
> 0000010
Das ist offenbar ISO 8859 kodiert.
> aber:
> % echo L<TAB>ï¿œsung| od -c
> 0000000 L o ? ** s u n g \n
> 0000011
>
> Ich kapier das nicht.
Deine Shell ist zu Intelligent. Das kommt halt davon, wenn die
Shell-schreiberlinge zu hilfsbereit sind und vermeindlich falsche
Umlautkodierungen meinen automagisch richten zu muessen.
Eine ordentliche Shell wuerde nur eine Variante korrekt darstellen und
du wuerdest sofort sehen, dass hier ein Locale-Mismatch vorliegt
zwischen deinem Terminal (der offenbar ISO8859 Kodierung verwendet)
und deiner Shell/Filesystem (die auf UTF-8 eingestellt sind).
Entsorge die zsh und verwende eine Shell die dich nicht verarschen will.
Leider kann ich dir nicht zur bash raten, denn das waere vom Regen in
die Traufe...
> In anderen Shells ist das genau so.
Fuer Werte von "andere Shells" aus der Menge { bash } mag das
zutreffen.
Dein eigentliches Problem ist aber gar nicht die kaputte Shell,
sondern die Fehleinstellung deines Terminalprogramms.
Du musst entweder dein System an dein Terminalprogramm anpassen oder
umgekehrt.
Ersteres kannst du mittels "export LC_CTYPE=de_DE.iso885915@euro"
umstellen ("locale -a" listet alle moeglichen Einstellungen in deinem
System auf), letzters indem du deinem Terminalprogramm beibringst,
UTF-8 zu verwenden.
HTH,
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Martin Kißner
> Deine Shell ist zu Intelligent. Das kommt halt davon, wenn die
> Shell-schreiberlinge zu hilfsbereit sind und vermeindlich falsche
> Umlautkodierungen meinen automagisch richten zu muessen.
>
> Eine ordentliche Shell wuerde nur eine Variante korrekt darstellen und
> du wuerdest sofort sehen, dass hier ein Locale-Mismatch vorliegt
> zwischen deinem Terminal (der offenbar ISO8859 Kodierung verwendet)
> und deiner Shell/Filesystem (die auf UTF-8 eingestellt sind).
Mein Terminalprogramm ist auf UTF-8 gestellt.
Mag sein, dass es fehlerhaft ist. Davon gehe ich aber im Augenblick
nicht aus.
Noch nicht verstanden habe ich, woraus Du schließt, dass die eine
Darstellung ISO8859 kodiert ist. Woraus leitest Du das ab?
> Entsorge die zsh und verwende eine Shell die dich nicht verarschen will.
> Leider kann ich dir nicht zur bash raten, denn das waere vom Regen in
> die Traufe...
Zu welcher Shell könntest Du mir denn raten?
>> In anderen Shells ist das genau so.
>
> Fuer Werte von "andere Shells" aus der Menge { bash } mag das
> zutreffen.
Nun, ich habe folgende Shells probiert:
bash, sh, zsh, ksh, csh, tcsh.
Das Ergebnis ist jedesmal das selbe.
> Dein eigentliches Problem ist aber gar nicht die kaputte Shell,
> sondern die Fehleinstellung deines Terminalprogramms.
>
> Du musst entweder dein System an dein Terminalprogramm anpassen oder
> umgekehrt.
>
> Ersteres kannst du mittels "export LC_CTYPE=de_DE.iso885915@euro"
> umstellen ("locale -a" listet alle moeglichen Einstellungen in deinem
> System auf),
% export LC_CTYPE=de_DE.iso885915@euro
echo L* | od -c
0000000 L o 314 210 s u n g \n
0000011
echo Lösung | od -c
0000000 L 303 266 s u n g \n
0000010
> HTH
Leider nicht wirklich, aber dennoch herzlichen Dank für Deine
Erläuterungen.
Gruß
Juergen P. Meier
> Juergen P. Meier wrote :
>
>> Deine Shell ist zu Intelligent. Das kommt halt davon, wenn die
>> Shell-schreiberlinge zu hilfsbereit sind und vermeindlich falsche
>> Umlautkodierungen meinen automagisch richten zu muessen.
>>
>> Eine ordentliche Shell wuerde nur eine Variante korrekt darstellen und
>> du wuerdest sofort sehen, dass hier ein Locale-Mismatch vorliegt
>> zwischen deinem Terminal (der offenbar ISO8859 Kodierung verwendet)
>> und deiner Shell/Filesystem (die auf UTF-8 eingestellt sind).
>
> Mein Terminalprogramm ist auf UTF-8 gestellt.
Dann steckt etwas zwischen deinem Terminalprogramm und deiner Shell,
die UTF8 in ISO8859 umwandelt.
> Mag sein, dass es fehlerhaft ist. Davon gehe ich aber im Augenblick
> nicht aus.
>
> Noch nicht verstanden habe ich, woraus Du schlieï¿œt, dass die eine
> Darstellung ISO8859 kodiert ist. Woraus leitest Du das ab?
Aus dem Hexdump deiner Eingabe. In UTF-8 besteht ein oe aus zwei Chars,
und zwar genau 0xC3 und 0xB6 (303 gefolgt 266 oktal)
> Zu welcher Shell kï¿œnntest Du mir denn raten?
Zu keiner besseren. Und das meine ich ausnahmsweise ernst.
>>> In anderen Shells ist das genau so.
>>
>> Fuer Werte von "andere Shells" aus der Menge { bash } mag das
>> zutreffen.
>
> Nun, ich habe folgende Shells probiert:
> bash, sh, zsh, ksh, csh, tcsh.
> Das Ergebnis ist jedesmal das selbe.
Dann ist wohl eher nicht die Shell der Ort, wo deine Umlaute verwandelt
werden. Uebrig bleibt dein Terminal sowie etwaitige Terminalemulatoren
dazwischen (screen?) und natuerlich dein Dateisystem.
>> Dein eigentliches Problem ist aber gar nicht die kaputte Shell,
>> sondern die Fehleinstellung deines Terminalprogramms.
>>
>> Du musst entweder dein System an dein Terminalprogramm anpassen oder
>> umgekehrt.
>>
>> Ersteres kannst du mittels "export LC_CTYPE=de_DE.iso885915@euro"
>> umstellen ("locale -a" listet alle moeglichen Einstellungen in deinem
>> System auf),
>
> % export LC_CTYPE=de_DE.iso885915@euro
>
> echo L* | od -c
> 0000000 L o 314 210 s u n g \n
> 0000011
Hmm, das kommt vom Filesystem und ist kein UTF-8. Was immer es ist, es
ist kein UTF-8.
Was kommt denn bei folgenden kommandos raus:
export LC_ALL=C
ls | grep sung | od -c
> echo Lï¿œsung | od -c
> 0000000 L 303 266 s u n g \n
> 0000010
Das schmeisst ein UTF-8 kodiertes Oe an dein od, welches die Zeichen
als ISO8858 kodiert interpretiert (Oktal 303 226 ist 0xC3B6 das UTF-8
oe).
D.h. dein Terminal produziert UTF8 wie du sagtest.
>> HTH
>
> Leider nicht wirklich, aber dennoch herzlichen Dank fï¿œr Deine
> Erlï¿œuterungen.
Was fuer ein Dateisystem und mit welchen Flags ist dieses gemountet?
Sven Mascheck
>>> % echo L�sung | od -c
>>> 0000000 L � ** s u n g \n
> % export LC_CTYPE=de_DE.iso885915@euro
> echo L�sung | od -c
> 0000000 L 303 266 s u n g \n
Eigentlich kann man aus der Ferne mit Sicherheit nur sagen,
da� Einstellungen bei Dir nicht zusammenpassen oder eines
der Programme UTF-8 nicht beherrscht.
Hier gibt viele subtile Fallen, weil alle beteiligten
Programme korrekt zusammenarbeiten m�ssen. Deshalb
ist ein systematisches Debugging erforderlich. Die L�sung
k�nnte im n�chsten Posting kommen oder erst nach weiteren
20 Fragen&Antworten.
Usenet ist Hilfe zur Selbsthilfe - deshalb mein Tip:
Starte mit einer definierten Ausgabe, z.B.
$ printf 'iso8859 oe: \366\nutf8 oe: \303\266\n'
und experimentiere mit verschiedenen Programmen
und Einstellungen. Achte darauf, da� eine �nderung
der Locale sich normalerweise nur auf danach neu gestartete
Programme auswirkt (als Ausnahme verfolgen manche Shells
diese Variable direkt).
Florian Diesch
>> Fuer Werte von "andere Shells" aus der Menge { bash } mag das
>> zutreffen.
>
> Nun, ich habe folgende Shells probiert:
> bash, sh, zsh, ksh, csh, tcsh.
> Das Ergebnis ist jedesmal das selbe.
Es hat auch nichts mit der Shell zu tun.
>> Dein eigentliches Problem ist aber gar nicht die kaputte Shell,
>> sondern die Fehleinstellung deines Terminalprogramms.
>>
>> Du musst entweder dein System an dein Terminalprogramm anpassen oder
>> umgekehrt.
>>
>> Ersteres kannst du mittels "export LC_CTYPE=de_DE.iso885915@euro"
>> umstellen ("locale -a" listet alle moeglichen Einstellungen in deinem
>> System auf),
Nein, das hilft nicht wirklich weiter, sonder bringt nur noch mehr
Probleme.
> % export LC_CTYPE=de_DE.iso885915@euro
>
> echo L* | od -c
> 0000000 L o 314 210 s u n g \n
> 0000011
"�" wird als o + U+0308 (COMBINING DIAERESIS) kodiert
> echo L�sung | od -c
> 0000000 L 303 266 s u n g \n
"�" wird als U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) kodiert
Du musst also entweder deinem Dateisystem abgew�hnen,
Kombinationszeichen-Sequenzen zu benutzen, oder deinem Terminal
beibringen, Umlaute als Kombinationszeichen-Sequenzen zu kodieren.
Florian
--
<http://www.florian-diesch.de/software/pdfrecycle/>
Stefan Reuther
>>0000000 L o ? ** s u n g \n
>>0000011
>
> Das ist wohl UTF-8 kodiert.
>
>>% echo Lï¿œsung | od -c
>>0000000 L ￜ ** s u n g \n
>>0000010
>
> Das ist offenbar ISO 8859 kodiert.
Das ist beides UTF-8-codiert. Nur wird im ersten Fall das "ￜ" aus zwei
Unicode-Zeichen erzeugt ("o" + combining diaeresis, ergibt drei Bytes),
im zweiten aus einem Unicode-Zeichen (ergibt zwei Bytes).
> Deine Shell ist zu Intelligent. Das kommt halt davon, wenn die
> Shell-schreiberlinge zu hilfsbereit sind und vermeindlich falsche
> Umlautkodierungen meinen automagisch richten zu muessen.
Unsinn.
> Dein eigentliches Problem ist aber gar nicht die kaputte Shell,
> sondern die Fehleinstellung deines Terminalprogramms.
Das hilft nur dann, wenn man das Terminalprogramm von Unicode-Normalform
C auf Normalform D umstellen kann. Und auch dann hilft es nur fï¿œr
Dateien, deren Name in decomposed-unicode ankommen (ï¿œblicherweise vom
Mac), schadet dafï¿œr bei Namen in precomposed-unicode (ï¿œblicherweise vom
Rest der Welt).
Ich bin ja der Meinung, sowas habe der Filesystemtreiber zu richten, der
ja eh schon an den Zeichen drehen muss, um andere iocharsets zu zu
unterstï¿œtzen. Aber auf mich hï¿œrt ja keiner.
Stefan
Martin Kißner
> Martin Kißner wrote:
>
>> % echo L* | od -c
>> 0000000 L o ? ** s u n g \n
>
> Auf die Darstellung mit doppelten Zeichen (** oder 88) kann
> ich mir immer noch keinen Reim machen.
> Übrigens: Da es ja auch noch via Usenet Darstellungsprobleme
> geben könnte, ist od -b letztendlich wohl das sicherste.
> man ascii ist dann hilfreich.
>
>> % echo Lösung | od -c
>> 0000000 L ö ** s u n g \n
>
> Das ist ein sehr direkter Hinweis: Bei Unicode dürfte
> hier kein Singlebyte-Umlaut entstehen.
Doch, ich glaube schon:
"Multi-byte characters are displayed in the area corre-
sponding to the first byte of the character.
The remaining bytes are shown as `**'." (man od)
Ich bin der Sache inzwischen soweit näher gekommen, als ich durch einen
Hinweis in einem Forum entdeckt habe, dass der Buchstabe ö auf zwei
unterschiedliche "Methoden" erzeugt werden kann:
Methode 1: Buchstabe o mit Diäresis "157 314 210"
% echo L* | od -b
0000000 114 157 314 210 163 165 156 147 012
0000011
Methode 2: multibyte ö "303 266"
% echo Lösung | od -b
0000000 114 157 314 210 163 165 156 147 012
0000011
Das Problem scheint zu sein, dass das Betriebssystem (oder wer auch
immer) in Dateinamen immer Methode 1 verwendet, auch wenn der Dateiname
Beim Erstellen der Datei mit Methode 2 gebildet wurde.
Die Shell/das Terminalprogramm arbeiten dafür anscheinend bevorzugt oder
generell mit Methode 2.
Ob´s dafür ne Lösung gibt, ist für mich im Augenblick fraglich.
Gruß
Martin Kißner
> Martin Kißner wrote:
>
>> % echo L* | od -c
>> 0000000 L o ? ** s u n g \n
>
> Auf die Darstellung mit doppelten Zeichen (** oder 88) kann
> ich mir immer noch keinen Reim machen.
> Übrigens: Da es ja auch noch via Usenet Darstellungsprobleme
> geben könnte, ist od -b letztendlich wohl das sicherste.
> man ascii ist dann hilfreich.
>
>> % echo Lösung | od -c
Doch, ich glaube schon:
Gruß
Martin
PS: Habe gerade gesehen, dass inzwischen weitere Beiträge gepostet
wurden, die ebenfalls in diese Richtung weisen. Ich selbst bin im
Augenblick mit meinen Bescheidenen Kenntnissen am Ende.
Das Einzige was mir noch einfällt ist ein Versuch mit den
Tastatureinstellungen des Terminalprogramms das 'ö' über eine
abenteuerliche Tastenkombination anstatt mit der 'ö' Taste zu erzeugen.
Andreas Kohlbach
>
> Was sagt "locale"?
Ich m�chte mal eine neue Frage einwerfen, ohne einen neuen Thread zu
�ffnen.
Ich nutze u.a. irssi auf einem OpenBSD System. Umlaute werden dort, aber
auch auf der tty (per ssh eingeloggt von einem Linux aus, auf dem lokal
irssi etc. mit Umlauten funktioniert), nicht angezeigt, bzw. als Zeichen
wie Karos.
Es scheint, "locale" gibt es dort nicht. Gibt es dort etwas, mit dem ich
als User (ich habe keine root Permissions) vielleicht Umlaute bekommen
kann?
--
Andreas
Linux: The choice of a GNU generation.
Juergen P. Meier
>> % export LC_CTYPE=de_DE.iso885915@euro
>>
>> echo L* | od -c
>> 0000000 L o 314 210 s u n g \n
>> 0000011
>
Stimmt. Das hatte ich uebersehen, dass es diese kanonisch aequvalente
Darstellung in Unicode gibt.
>> echo Lï¿œsung | od -c
>> 0000000 L 303 266 s u n g \n
>
> "ￜ" wird als U+00F6 (LATIN SMALL LETTER O WITH DIAERESIS) kodiert
Beides sind also korrekte UTF-8 Kodierungen des UNICODE Umlautes "ￜ".
> Du musst also entweder deinem Dateisystem abgewï¿œhnen,
> Kombinationszeichen-Sequenzen zu benutzen, oder deinem Terminal
> beibringen, Umlaute als Kombinationszeichen-Sequenzen zu kodieren.
Ersteres ist wohl sinnvoller. U+00FC ist wohl gaengier als U+006F mit
U+0308. Zumal letzteres bei einer Shell durchaus Probleme machen
koennte - denn wie ist mit zwei Unicode-Zeichen, die ein Zeichen
ergeben zu verfahren?
Sven Mascheck
> Ich m锟絚hte mal eine neue Frage einwerfen, ohne einen neuen Thread zu
> 锟絝fnen.
w锟絩e aber angemessen.
> Ich nutze u.a. irssi auf einem OpenBSD System. Umlaute werden dort, aber
> auch auf der tty (per ssh eingeloggt von einem Linux aus, auf dem lokal
> irssi etc. mit Umlauten funktioniert), nicht angezeigt, bzw. als Zeichen
> wie Karos.
>
> Es scheint, "locale" gibt es dort nicht. Gibt es dort etwas, mit dem ich
> als User (ich habe keine root Permissions) vielleicht Umlaute bekommen
> kann?
Da locale(1) nicht implementiert ist, ist setlocale(3) ein guter Start
in der Doku: Die "Infrastruktur" f锟絩 locales ist vorhanden, unterst锟絫zt
aber nur LC_CTYPE - das ist das, was Du ben锟絫igst (wenn das Programm
setlocale() verwendet und es nicht einfach drauf ankommen l锟斤拷t).
Hier wird au锟絜rdem auf mklocale(1) verwiesen: die g锟絣tigen Werte findet
man also in /usr/share/locale/.
Falls perl installiert ist, ist das 锟絙rigens ein eleganter Weg,
herauszufinden, ob ein setlocale() erfolgreich w锟絩e,
$ LC_CTYPE=de_DE perl
perl: warning: Setting the locale failed.
[...] <ctrl-c>
$ LC_CTYPE=de_DE.ISO8859-1 perl
<ctrl-c>
$
Damit sind aber Konsole und Zeichensatz noch nicht behandelt.
Ein guter Start ist wohl wscons(4). F锟絩 OpenBSD-Versionen
vor 2.9 empfehle ich ein 锟絣teres Posting von Christian Weisgerber,
http://groups.google.com/group/de.comp.os.unix.bsd/msg/6d6587fa295b85c8
--
http://www.in-ulm.de/~mascheck/locale/#checklocale
David Haller
>> ls L*|od -a
>> 0000000 L o ? 88 s u n g nl
>
Ist 'od -tx1z' eigentlich portabel?
-dnh
--
Never be afraid to try something new. Remember, amateurs built the
ark; professionals built the Titanic. -- Anonymous
Martin Kißner
> Sven Mascheck <masc...@email.invalid> wrote:
>>> ls L*|od -a
>>> 0000000 L o ? 88 s u n g nl
>>
>
> Ist 'od -tx1z' eigentlich portabel?
Nein:
% ls -l L* | od -tx1z
od: z: unrecognised format character
Thomas Rachel
> Du musst also entweder deinem Dateisystem abgewöhnen,
> Kombinationszeichen-Sequenzen zu benutzen,
Das Dateisystem verwendet unter UNIXartigen Systemen einfach
nullterminierte Binärstrings. Wem auf die Füße zu treten ist, ist der
Ersteller.
War es nicht so, daß Mac-Systeme diese kombinierten (o + Diaresis)
Zeichen verwendet und andere Systeme die "einfachen" Symbole?
> oder deinem Terminal beibringen, Umlaute als
Kombinationszeichen-Sequenzen zu kodieren.
Tut es ja vermutlich auch - beide ö werden als ö angezeigt (denk ich
jetzt mal).
Thomas
Sven Mascheck
> Die "Infrastruktur" f�r locales ist vorhanden, unterst�tzt aber nur LC_CTYPE
...und LC_MESSAGES nat�rlich, mit eigenen Funktionen wie gettext(),
sonst g�be es ja keine lokalisierten Meldungen.
David Haller
> David Haller wrote :
>> Sven Mascheck <masc...@email.invalid> wrote:
>>>> ls L*|od -a
>>>> 0000000 L o ? 88 s u n g nl
>>>
>>
>> Ist 'od -tx1z' eigentlich portabel?
>
> Nein:
> % ls -l L* | od -tx1z
> od: z: unrecognised format character
Wie schade. Die Kombination aus -t x1 und sowas wie '-c' ist einfach
praktisch. Naja. Ich hab zur Not auch ein eigenes 'hexdump.c' ;)
-dhn
--
50: Version x.1
Kostenpflichtiger Bugfix (Kristian Kï¿œhntopp)
Martin Kißner
> Martin Kißner <ne...@chaos-net.de> wrote:
>> David Haller wrote :
>>> Sven Mascheck <masc...@email.invalid> wrote:
>>>>> ls L*|od -a
>>>>> 0000000 L o ? 88 s u n g nl
>>>>
>>>
>>> Ist 'od -tx1z' eigentlich portabel?
>>
>> Nein:
>> % ls -l L* | od -tx1z
>> od: z: unrecognised format character
>
> Wie schade. Die Kombination aus -t x1 und sowas wie '-c' ist einfach
> praktisch.
Das geht bei mir so:
% ls L* | od -tx1c
0000000 4c 6f cc 88 73 75 6e 67 0a
L o ̈ ** s u n g \n
0000011
Und ja, es ist praktisch. Danke für den Tipp.
Martin Kißner
Ja sicher. Inzwischen bin ich durch Zufall auf einen Hinweis gestoßen,
der die Sache einigermaßen nachvollziehbar, wenn auch dadurch nicht
akzeptabel, macht.
Es scheint so, als ob das unter Mac OS X übliche Dateisystem HSF+
Dateinamen die Umlaute enthalten automatisch "zerlegt" und die Umlaute
in die Form mit Diaresis umwandelt, auch wenn bei der Erstellung des
Dateinamens die Form ohne Diaresis verwendet wird.
Aus diesem Grund kennt die Mac-Version des Konsolenprogramms iconv auch
ein pseudo encoding UTF8-MAC (auch UTF-8-MAC).
Damit kann man das auch nachvollziehen:
# Das touch Kommando erhält das ü im Dateinamen als "303 274"
# Die Datei wird so erstellt
% echo touch übung | od -b -tc
0000000 164 157 165 143 150 040 303 274 142 165 156 147 012
t o u c h ü ** b u n g \n
0000015
% touch übung | od -b -tc
# Der Dateiname wird mit "echo" ausgegeben - das ü ist jetzt plötzlich
# als "165 314 210" kodiert, also u mit Diaresis.
% echo *bung | od -b -tc
0000000 165 314 210 142 165 156 147 012
u ̈ ** b u n g \n
0000010
# Mit iconv kann man die Ausgabe dann wieder von "UTF8-MAC" in
# 'normales' UTF-8 umwandeln.
% echo *bung | iconv -f UTF8-MAC -t UTF8 | od -b -tc
0000000 303 274 142 165 156 147 012
ü ** b u n g \n
0000007
Schön, jetzt weiß ich also, was passiert, aber wie kann ich nun in der
Shell vernünftig mit Umlauten arbeiten? Mein Terminalprogramm erzeugt
bei Eingabe der Taste ü "303 274" In Dateinamen wird aber grundsätzlich
eine andere Kodierung verwendet. Folge: Tabvervollständigung und
wildcards können nicht funktionieren.
Ratlose Grüße
Ansgar Strickerschmidt
> Schön, jetzt weiß ich also, was passiert, aber wie kann ich nun in der
> Shell vernünftig mit Umlauten arbeiten? Mein Terminalprogramm erzeugt
> bei Eingabe der Taste ü "303 274" In Dateinamen wird aber grundsätzlich
> eine andere Kodierung verwendet. Folge: Tabvervollständigung und
> wildcards können nicht funktionieren.
Deiner Shell (welcher??) ein anderes Encoding in ihrer Konfigurationsdatei
vorgeben.
Ansgar
--
*** Musik! ***