Umlaute im Dateinamen in Terminal sonderbar

F

fantaeiner

Mitglied
Thread Starter
Dabei seit
09.11.2014
Beiträge
84
Reaktionspunkte
5
Hallo,

wie ist das mit den Umlauten im Dateinamen im Terminal?

Wenn ich mir die Dateien in einem Verzeichnis anzeigen lassen, dann sieht z.B. das ö etwas sonderbar aus, jedenfalls anders als wenn ich es eintippen würde.
Ich kann auch beliebig oft "mv hörbar.sh hörbar.sh" ohne Fehlermeldung ausführen, wobei der erste Dateiname nur mit Tab-Vervollständigung erstellt werden kann und der zweite Dateiname getippt ist. Das ö der Tastatur zu dem sonderbaren ö im Dateinamen ausgestauscht.
Ein Bild habe ich auch noch engehängt, auf dem man sieht, dass der Umlaut ö der Datei nicht derselbe der Tastatur ist und dass der Befehl keine Fehlermeldung produziert und wiederholbar ist

Weiß jemand, was hier das Problem sein könnte?

fragt
fantaeiner

hoerbar.jpg
 
großes Ö versus kleine ö …
bei dem font scheint der unterschied nicht wesentlich zu sein.
müsste man mal den code von dem zeichen sehen …
 
Ein großes Ö ist das nicht, denn das sieht noch einmal anders aus. Wie kann ich denn den Code von dem "falschen" ö-Zeichen ermitteln?
 
ls h*rbar.sh | hexdump -C ergibt bei mir:

00000000 68 6f cc 88 72 62 61 72 2e 73 68 0a |ho..rbar.sh.|
0000000c

hilft Euch das weiter?
 
Bei dir wird das "ö" aus drei Bytes zusammengesetzt (6f cc 88) - das wird bei meinem Texteditor, wenn ich es so im Hex-Editor-Modus eingebe, als UTF-8 erkannt und als ö dargestellt. Wenn ich im Texteditor hingegen zuerst auf UTF-8 einstelle und dann ein ö eingebe, wird es als c3 b6 kodiert.

Deine Variante ist der zusammengesetzte Modus bei UTF-8: 6f ist ein normales o, dann die Punkte als Modifier (COMBINING DIAERESIS) "darangeklebt". Siehe http://www.fileformat.info/info/unicode/char/0308/index.htm
 
Das ist ja interessant! Aber was kann ich nun machen, damit im Terminal ein ö ein nicht ein o mit Punkten ist?
 
Du musst deinem Terminal sagen, dass du ihm UTF-8 gibst. Welche Werte haben denn LC_CTYPE bzw. LANG bei dir? iTerm sollte die übrigens automatisch anpassen.
 
Ich glaube im Terminal ist das schon korrekt eingestellt, sonst würde er die UTF-8-Zeichen mit COMBINING DIAERESIS ja gar nicht richtig anzeigen. Sie sind richtig. Nur eben nicht gleich zu den Umlauten in UTF-8 ohne COMBINING.

UTF-8 definiert eine Normalisierung, die dafür sorgen müsste, dass die beiden Zeichen gleich dargestellt werden. Aber ich weiß nicht, ob das zur Schriftart gehört (@fantainer: Klappt's denn in einer anderen Schriftart? Probier's mal bitte mit San Francisco Mono (SF Mono)) oder Aufgabe des Terminals ist.
 
HFS+ speichert die unicode zeichen in dateinamen übrigens immer in einer bestimmten form.
vielleicht kommt das daher …
 
Wenn's das wäre, könnte fantainer mit seinem mv-Befehl den Umlaut nicht von einer Form in die andere umwandeln. HFS+ unterstützt also offensichtlich beide Varianten.
 
Eine Änderung der Schriftart im Terminal bringt leider keine Änderung.

LC_CTYPE ist leer und LANG=de_DE.UTF-8
 
Was kann ich nun den machen, damit Terminal die richtigen Buchstaben aus dem Dateinamen anzeigt?
 
Es zeigt doch die richtigen an? Das zusammengesetzte "ö" ist ein anderes Zeichen als das normale. Mit welchem Programm wurden die Dateien denn erstellt?
 
andi42 schrieb:
Es zeigt doch die richtigen an? Das zusammengesetzte "ö" ist ein anderes Zeichen als das normale.
Zum Vergrößern anklicken....
Sehe ich ebenfalls so. Ist halt fies, da man es nicht direkt sehen kann, aber 力 und カ sind auch verschieden und dennoch sehr ähnlich (in manchen Schriftarten noch deutlich ähnlicher als hier in dieser, die das Forum nutzt).

thorstenhirsch schrieb:
UTF-8 definiert eine Normalisierung, die dafür sorgen müsste, dass die beiden Zeichen gleich dargestellt werden.
Zum Vergrößern anklicken....
Leider nicht nur eine Normalform und Apple benutzt für HFS+ eine, die der Rest der Welt nicht nutzt, wodurch ständiges Konvertieren angesagt ist, das leider auch mal schief geht.

Tatsächlich glaube ich aber auch, dass das mit dem Problem des TEs absolut nichts zu tun hat. Das hier sieht mir nach einer Zeichenersetzung aus einer anderen Schrift aus. Hat der TE mal andere Schriftarten getestet? Bedingt durch mein US Layout nutze ich für Umlaute immer die zusammengesetzte Form (¨ + u = ü), aber bei mir sieht diese ü und ein "echtes" ü im Terminal gleich aus.
 
Kleiner Einwurf noch: um welches Problem genau geht es denn? Mein vorheriger Post geht von dem Problem aus, dass die Zeichen unterschiedlich aussehen.
Wenn es um das matchen geht, dann vermute ich ist da in der Tat die OSX'sche Normalisierung schuld. Da hatte ich kürzlich erst einen ähnlichen Fall gesehen: https://github.com/mpv-player/mpv/issues/4016#issuecomment-272178721
Ich zitiere weiter einen Commit daraus, der genau das Anspricht:
several unicode characters can be encoded in two different ways, either
in a precomposed (NFC) or decomposed (NFD) representation. everywhere
besides on macOS, specifically HFS+, precomposed strings are being used.
furthermore on macOS we can get either precomposed or decomposed
strings, for example when not HFS+ formatted volumes are used. that can
be the case for network mounted devices (SMB, NFS) or optical/removable
devices (UDF). this can lead to an inequality of actual equal strings,
which can happen when comparing strings from different sources, like the
command line or filesystem.
Zum Vergrößern anklicken....
Genau wie der verlinkte Player müsste auch Bash eine extra Konvertierung/Re-Normalisierung von Strings auf OSX (und nur OSX...) einführen um das Problem korrekt zu beheben.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten