Discussion:
Programm 'tree' und die Umlaute
(zu alt für eine Antwort)
Stefan Kresse
2008-05-23 10:57:09 UTC
Permalink
Hallo ihr wissenden Leute,

ich versuche momentan, das Programm 'tree' für ein eigenes Opt zu
kompilieren. Da sich die aktuelle Version 1.5.x nicht im fli4l
buildroot kompilieren lässt, weil diverse Header fehlen, habe ich
Version 1.4b3 benutzt. Die lässt sich auch wunderbar kompilieren und
auf dem fli4l ausführen.

Problem ist nun, dass er keinerlei Umlaute ausgibt, die werden einfach
weggelassen, so dass aus
küche.txt
ein
kche.txt
wird.

Die ash in der Busybox gibt den Dateinamen korrekt aus.
Wie kann ich dieses Problem beheben?

Falls es wichtig sein sollte: benutze fli4l 3.0.4 und das fbr läuft in
einem Knoppix 5.1.1 per chroot.

Das Gleiche Problem habe ich auch bei anderen Tools, die ich
kompilieren will (unter anderem fileutils, bash).

Ich danke schonmal
MfG Stefan Kresse
Friedrich Bartel
2008-05-23 13:17:00 UTC
Permalink
Post by Stefan Kresse
Hallo ihr wissenden Leute,
ich versuche momentan, das Programm 'tree' für ein eigenes Opt zu
kompilieren. Da sich die aktuelle Version 1.5.x nicht im fli4l
buildroot kompilieren lässt, weil diverse Header fehlen, habe ich
Version 1.4b3 benutzt. Die lässt sich auch wunderbar kompilieren und
auf dem fli4l ausführen.
Problem ist nun, dass er keinerlei Umlaute ausgibt, die werden einfach
weggelassen, so dass aus
küche.txt
ein
kche.txt
wird.
Die ash in der Busybox gibt den Dateinamen korrekt aus.
Wie kann ich dieses Problem beheben?
Falls es wichtig sein sollte: benutze fli4l 3.0.4 und das fbr läuft in
einem Knoppix 5.1.1 per chroot.
Das Gleiche Problem habe ich auch bei anderen Tools, die ich
kompilieren will (unter anderem fileutils, bash).
Ich danke schonmal
MfG Stefan Kresse
Ich tippe da auf den Zeichensatz vom flie3.0.4 und Knoppix.

Das selbe habe ich im phonebook. Namen mit deutschen Umlauten
kann es nicht darstellen, die sind auf der Tastatur auch nicht
belegt.

Mir wurde gesgt, das man unter Linux/Unix keine Verzeichnisse
oder Dateien mit Umlauten anlegen sollte.
Im englischen gibt es auch keine und das gesamte Linux basiert
darauf. Mit eingedeutschen Dateitools geht das leider.

Das die deutschen Windowsweltler das auf Sambalaufwerken tun und
Samba dann ins Nivana verschwindet ist schon klar. Selbst aber
auf Windows-FAT32 und NTFS-Partitionen führt das zu manchmal
fröhlichen Datei- und Verzeichnisverlusten.

Du bist schon auf den richtigen Weg. Es gibt keine Umlaute und ß
Sonderzeichen zu beachten, weil Deutsch eine Kunstsprache ist.

Die Variable Ö würde Dir den Compiler abschießen, oder das
System.


Friedrich
Stefan Kresse
2008-05-23 14:11:36 UTC
Permalink
Post by Friedrich Bartel
Ich tippe da auf den Zeichensatz vom flie3.0.4 und Knoppix.
Ja, in Richtung Zeichensatz habe ich auch gedacht.
Aber das Knoppix sollte eigentlich keinen Einfluss auf das Kompilat
haben, weil ich ja im Buildroot baue.
Post by Friedrich Bartel
Mir wurde gesgt, das man unter Linux/Unix keine Verzeichnisse
oder Dateien mit Umlauten anlegen sollte.
Im englischen gibt es auch keine und das gesamte Linux basiert
darauf. Mit eingedeutschen Dateitools geht das leider.
Linux bewegt sich aber dank libiconv und gettext und anderen
Libs/Tools in Richtung Multilanguage und dank UTF-8 gibt's auch die
passenden Zeichen. Und das finde ich auch gut so.
Post by Friedrich Bartel
Das die deutschen Windowsweltler das auf Sambalaufwerken tun und
Samba dann ins Nivana verschwindet ist schon klar.
Hö? Ist mir noch nie passiert und ich arbeite viel mit Samba und
dessen Freigaben.
Post by Friedrich Bartel
Selbst aber
auf Windows-FAT32 und NTFS-Partitionen führt das zu manchmal
fröhlichen Datei- und Verzeichnisverlusten.
Das höre ich zum ersten Mal. Noch niemals sind bei mir Dateien
aufgrund von Umlauten verloren gegangen oder waren nicht mehr lesbar
o.ä. Sachen. Kann IMHO auch nicht sein, solange ich ausschließlich in
ein- und demselben Zeichensatz arbeite.
Post by Friedrich Bartel
Du bist schon auf den richtigen Weg. Es gibt keine Umlaute und ß
Sonderzeichen zu beachten, weil Deutsch eine Kunstsprache ist.
Dann weise ich mal auf folgendes hin:
Das Opt_Info vom fli4l 2.0.x enthielt ein 'tree' (Version 1.0), das
die Umlaute problemlos darstellen konnte.
Ich könnte jetzt den Autor des Pakets kontaktieren, aber ich dachte,
dass ich hier evtl. schneller Hilfe finde.
Und wieso ist Deutsch eine Kunstsprache? Deutsch hat sich genau wie
andere Sprachen aus Latein entwickelt und hat verschiedenste Einflüsse
anderer Sprachen übernommen.
Davon abgesehen gibt's Umlaute auch in vielen anderen Sprachen;
Deutsch bildet da keine Ausnahme.
Post by Friedrich Bartel
Die Variable Ö würde Dir den Compiler abschießen, oder das
System.
Um Variablen geht's mit ja auch nicht, sondern ausschließlich um
Dateinamen ;-)

MfG Stefan Kresse
Friedrich Bartel
2008-05-23 18:56:23 UTC
Permalink
Post by Stefan Kresse
Linux bewegt sich aber dank libiconv und gettext und anderen
Libs/Tools in Richtung Multilanguage und dank UTF-8 gibt's auch die
passenden Zeichen. Und das finde ich auch gut so.
Linux benutzt zwar inzwischen UTF-8, Windows hingegen CP125X und
der Kuddelmuddel beginnt, wenn ein Windows einen Dateinamen mit
Umlauten auf einem UTF-8 Linux setzt.
Post by Stefan Kresse
Post by Friedrich Bartel
Das die deutschen Windowsweltler das auf Sambalaufwerken tun und
Samba dann ins Nivana verschwindet ist schon klar.
Hö? Ist mir noch nie passiert und ich arbeite viel mit Samba und
dessen Freigaben.
Ich hatte Samba bis zur SuSE 9 im Gebrauch, trotzdem gab es
einige Probleme. Mal gab es die Freigaben, mal wieder nicht.
Das Sambachen hielt auch beim Dateienkopieren auch mal gern ein
Nickerchen. Letztendlich gab ich Samba zugunsten eines
Windowsservers auf. Wie die neuen Sambas sind weiß ich nicht.

Andersrum, von einer Knoppix auf einen XP2003 Server zu kommen
und dort freigegebene Verzeichnisse zu mounten ist kein Thema.

Im Eisfairtrhreat hat jemand heute geschrieben, das sein Samba
und EIS nach längerer Kopieraktion zum closed shop geworden ist.
Ursachen dafür gibt es manigfaltige aber mutmaßlich geht das in
die Richtung, weil Dateinamen, die von den Windowsclients
angelegt worden sind, Umlaute enthielten.

Windows ist eben zu nichts kompatibel, ausser zu sich selbst.
:-)
Post by Stefan Kresse
Das höre ich zum ersten Mal. Noch niemals sind bei mir Dateien
aufgrund von Umlauten verloren gegangen oder waren nicht mehr lesbar
o.ä. Sachen. Kann IMHO auch nicht sein, solange ich ausschließlich in
ein- und demselben Zeichensatz arbeite.
Unter Windows hatte ich das Problem oft, das sowas nicht
diskutiert wird verwundert.
http://forum.ubuntuusers.de/topic/119277/next/
Post by Stefan Kresse
Das Opt_Info vom fli4l 2.0.x enthielt ein 'tree' (Version 1.0), das
die Umlaute problemlos darstellen konnte.
Also ich hab einen 2.0.8 und tree läuft da auch. Sicher zeigt
der Umlaute an, aber ein ls oder dir nicht. Das zeigt nur K?che
wechselt man in K?che ist der Pfad /Küche. Der Standartanwender
wird nicht mehr eingeben wollen als ls und dir.

Aber Insider wissen bei Linux-Filesystemen wie ReiserFS:
http://www.kanotix.com/PNphpBB2-viewtopic-t-24669.html

und ext2 und ext3
http://www.pro-linux.de/news/2006/9938.html

Und die WinDosen jammern:
http://www.open7x0.org/arena/showthread.php?tid=2137

Also doch ein Linux ohne UTF-8-Encoding verwenden?
Post by Stefan Kresse
Davon abgesehen gibt's Umlaute auch in vielen anderen Sprachen;
Deutsch bildet da keine Ausnahme.
Umlaute ja aber, Lateinische und kyrillische sprachspezifische
Zeichen erscheinen als Zeichensalat, aber man kann die Dateien
öffnen.

Wenn ich auf dem Fli208 mit meinen Totalcommander gehe und im
Phonebook den Namen Müller eingtrage wird der im
Midnight Commander als M.ller angezeigt.
Post by Stefan Kresse
Um Variablen geht's mit ja auch nicht, sondern ausschließlich um
Dateinamen ;-)
War nur ein Beispiel. Was ich sagen will, ist das ein
Linuxsystem mit Umlauten problematisch ist.

http://www.uni-muenster.de/ZIV/Mitarbeiter/MathiasGrote/linux/Dateisystem.html

Absatz Namen Zitat:
Dateinamen

* sind maximal 255 Zeichen lang,
* unterscheiden Groß- und Kleinbuchstaben,
* müssen innerhalb eines Verzeichnisses eindeutig sein,
* sollten keine Sonderzeichen enthalten. Schon Umlaute sind
problematisch
Post by Stefan Kresse
MfG Stefan Kresse
dito und viel Erfolg


Friedrich
Stefan Kresse
2008-05-23 20:21:02 UTC
Permalink
Post by Friedrich Bartel
Linux benutzt zwar inzwischen UTF-8, Windows hingegen CP125X und
der Kuddelmuddel beginnt, wenn ein Windows einen Dateinamen mit
Umlauten auf einem UTF-8 Linux setzt.
Die "kompletten" (großen) Distributionen benutzen UTF-8, richtig, aber
mir scheint das bei fli4l nicht der Fall zu sein.
Jedenfalls bekomme ich bei den Umlauten nur Müll auf den Bildschirm,
wenn ich eine Partition mit UTF-8 mounte.
Post by Friedrich Bartel
Ich hatte Samba bis zur SuSE 9 im Gebrauch, trotzdem gab es
einige Probleme. Mal gab es die Freigaben, mal wieder nicht.
Das Sambachen hielt auch beim Dateienkopieren auch mal gern ein
Nickerchen. Letztendlich gab ich Samba zugunsten eines
Windowsservers auf. Wie die neuen Sambas sind weiß ich nicht.
Tja, das ist aber ein Problem von Samba.
Inzwischen benutzt Samba ebenfalls UTF-8 und das funktioniert bei mir
reibungslos. Einziges Problem ist nur die Ausgabe auf den HTTPD, der
mit ISO8859-1 arbeitet... Aber da kann Samba nix für.
Post by Friedrich Bartel
Windows ist eben zu nichts kompatibel, ausser zu sich selbst.
Und das noch nicht mal in allen Fällen ;D
Post by Friedrich Bartel
Also ich hab einen 2.0.8 und tree läuft da auch. Sicher zeigt
der Umlaute an, aber ein ls oder dir nicht. Das zeigt nur K?che
wechselt man in K?che ist der Pfad /Küche. Der Standartanwender
wird nicht mehr eingeben wollen als ls und dir.
Es geht mir bei tree weniger um die Eingabe auf der Konsole/Terminal,
sondern ich will das in einem CGI verwenden.
Das ls des opt_bash zeigt die Umlaute auf dem 2.0.8 auch korrekt an,
genau wie das tree auf derselben Maschine.

Übrigens heißt das Wort Standardanwender. Standart ist eine Art zu
stehen oder ein Obst-/Gemüsestand ;-)
Post by Friedrich Bartel
http://www.kanotix.com/PNphpBB2-viewtopic-t-24669.html
und ext2 und ext3
http://www.pro-linux.de/news/2006/9938.html
http://www.open7x0.org/arena/showthread.php?tid=2137
Da es (in diesem speziellen Fall) um Dateisysteme auf CDs geht (also
ISO9660), wird das nix mit anderen Dateisystemen.
Post by Friedrich Bartel
Also doch ein Linux ohne UTF-8-Encoding verwenden?
Wie gesagt: fli4l ist wohl ohne (komplette) UTF-8 Unterstützung, oder
zumindest nicht per default eingeschaltet (muss ja auch nicht).
Auf einem Knoppix habe ich jedenfalls keine Probleme,
Datei-/Verzeichnisnamen mit UTF-8 drin anzuzeigen/zu verarbeiten.
Post by Friedrich Bartel
Wenn ich auf dem Fli208 mit meinen Totalcommander gehe und im
Phonebook den Namen Müller eingtrage wird der im
Midnight Commander als M.ller angezeigt.
Es kommt darauf an. Bei dem neu aufgesetzten fli4l 3.0.4 reagiert der
MC anders als das Kommando ls im Terminal.
Außerdem ist der Zeichensatz des Samba wichtig.
Ich hab mir den neusten stable selbst kompiliert und der nutzt UTF-8
und das lässt sich auch nicht wirklich funktionierend ändern.
Der alte Samba hat ISO8859-1 verwendet und dort sollten die
Sonderzeichen eigtl. alle korrekt dargestellt werden können.
Post by Friedrich Bartel
http://www.uni-muenster.de/ZIV/Mitarbeiter/MathiasGrote/linux/Dateisystem.html
Dateinamen
* sind maximal 255 Zeichen lang,
* unterscheiden Groß- und Kleinbuchstaben,
* müssen innerhalb eines Verzeichnisses eindeutig sein,
* sollten keine Sonderzeichen enthalten. Schon Umlaute sind
problematisch
Mag sein. Aber ich halte das im Jahr 2008 für Irrsinn und nicht mehr
praktikabel. Ich will einfach alle Zeichen der jeweiligen Sprache
nutzen (und zwar überall) und fertig.
Post by Friedrich Bartel
dito und viel Erfolg
Ein Teilerfolg hat sich ja schon eingestellt.

MfG Stefan Kresse
Arwin Vosselman
2008-05-23 16:43:48 UTC
Permalink
Hallo Friedrich,
Post by Friedrich Bartel
Das selbe habe ich im phonebook. Namen mit deutschen Umlauten
kann es nicht darstellen, die sind auf der Tastatur auch nicht
belegt.
Falsches Tastaturlayout eingestellt?
--
Gruss,
Arwin.
Arwin Vosselman
2008-05-23 16:40:40 UTC
Permalink
Hallo Stefan,
Post by Stefan Kresse
Problem ist nun, dass er keinerlei Umlaute ausgibt, die werden einfach
weggelassen, so dass aus
küche.txt
ein
kche.txt
wird.
Die ash in der Busybox gibt den Dateinamen korrekt aus.
Wie kann ich dieses Problem beheben?
Hast Du 'tree -N' probiert?

Aus usage:
-N Print non-printable characters as is.
--
Gruss,
Arwin.
Stefan Kresse
2008-05-23 17:36:02 UTC
Permalink
Post by Arwin Vosselman
Hast Du 'tree -N' probiert?
-N Print non-printable characters as is.
Nein, hab ich wohl übersehen. Danke.
Kann man das als default setzen beim Kompilieren oder zur Laufzeit
(z.B. per Umgebungsvariable)?

Deine Frage hat mich auf die Idee gebracht, das 'ls' aus den fileutils
mal mit dem Parameter --show-control-chars zu starten und auch dort
sehe ich nun die Umlaute :-). Danke!
Hierbei weiß ich, wie ich das zum default machen kann in
Zusammenarbeit mit der Bash.

Klappt aber bei beiden nur, wenn es kein Unicode, sprich UTF-8, ist.
Bekommt man das auch noch irgendwie hin?

MfG Stefan Kresse
Arwin Vosselman
2008-05-23 17:59:26 UTC
Permalink
Hallo Stefan,
Post by Stefan Kresse
Post by Arwin Vosselman
-N Print non-printable characters as is.
Nein, hab ich wohl übersehen. Danke.
Kann man das als default setzen beim Kompilieren oder zur Laufzeit
(z.B. per Umgebungsvariable)?
Ich denke nicht dass das vorgesehen ist. Du kannst aber die Sources patchen
(Nflag = TRUE). Siehe Zeilen 133, 174 und eventuell 1035 von tree.c.
Beachte aber den LICENSE, es ist kein GPL!
Post by Stefan Kresse
Klappt aber bei beiden nur, wenn es kein Unicode, sprich UTF-8, ist.
Bekommt man das auch noch irgendwie hin?
Da habe ich keine Ahnung.
--
Gruss,
Arwin.
Stefan Kresse
2008-05-23 18:24:03 UTC
Permalink
Post by Arwin Vosselman
Post by Stefan Kresse
Kann man das als default setzen beim Kompilieren oder zur Laufzeit
(z.B. per Umgebungsvariable)?
Ich denke nicht dass das vorgesehen ist. Du kannst aber die Sources patchen
(Nflag = TRUE). Siehe Zeilen 133, 174 und eventuell 1035 von tree.c.
Ah, OK. Kommt ja nur Zeile 174 in Frage.
Post by Arwin Vosselman
Beachte aber den LICENSE, es ist kein GPL!
Ab Version 1.5 ist es GPL. Kann man jetzt drüber diskutieren, ob das
eine Rolle spielt.
Aber soo wichtig ist dieser default nun auch wieder nicht.
Schließlich kann ich den Parameter in meinem Opt mit angeben.
Post by Arwin Vosselman
Post by Stefan Kresse
Klappt aber bei beiden nur, wenn es kein Unicode, sprich UTF-8, ist.
Bekommt man das auch noch irgendwie hin?
Da habe ich keine Ahnung.
Schade. Aber evtl. meldet sich ja noch jemand.

MfG Stefan Kresse
Arwin Vosselman
2008-05-23 19:26:55 UTC
Permalink
Hallo Stefan,
Post by Stefan Kresse
Post by Arwin Vosselman
Beachte aber den LICENSE, es ist kein GPL!
Ab Version 1.5 ist es GPL. Kann man jetzt drüber diskutieren, ob das
eine Rolle spielt.
Ich habe keine Lust die LICENSE zu studieren, wenn Du aber ein OPT bauen
willst und in der OPT-DB ablegen willst, werden die OPT-COPs schon
ddar"uber entscheiden. GPL ist einfach kein Problem.

Was war genau das Problem mit der Version 1.5.0? Sources habe ich
inzwischen gefunden.
Post by Stefan Kresse
Aber soo wichtig ist dieser default nun auch wieder nicht.
Schließlich kann ich den Parameter in meinem Opt mit angeben.
Genau.
--
Gruss,
Arwin.
Stefan Kresse
2008-05-23 19:58:40 UTC
Permalink
Post by Arwin Vosselman
Ich habe keine Lust die LICENSE zu studieren, wenn Du aber ein OPT bauen
willst und in der OPT-DB ablegen willst, werden die OPT-COPs schon
ddar"uber entscheiden. GPL ist einfach kein Problem.
Sollen sie auch. Aber da es um SambaCD geht, wird das eh nicht in der
offiziellen Opt-DB landen.
Bisher ist das Opt nur in privatem Gerbrauch, dafür wäre die Lizenz
unwichtig (so weit ich das gelesen und verstanden hab).
Post by Arwin Vosselman
Was war genau das Problem mit der Version 1.5.0? Sources habe ich
inzwischen gefunden.
Es wurde Internationalisierung eingebaut, aber entsprechende Header
fehlen dem fbr. Wenn ich gettext installiere (hab irgendeine 0.14er
Version drin), dann kompiliert er trotzdem nicht, weil er die wchar.h
und wctype.h nicht findet, obwohl er sie in seinem eigenen Verzeichnis
liegen hat.
Wenn ich die tree.c so verändere, dass statt <wchar.h> ein "wchar.h"
steht, kommen auch nur Fehlermeldungen (weiß jetzt nicht mehr,
welche).

Im Knoppix selbst lässt sich die Version 1.5 problemlos übersetzen. Es
kommen nur 3 oder 4 Warnungen bzgl. der "signedness" versch.
Variablen.

Mich würde am ehesten interessieren, warum die ash aus der busybox die
Umlaute ohne zusätzliche Parameter anzeigt und die von mir kompilierte
Bash (bzw. das ls aus den fileutils) nur mit Parameter.
Kann man die Kompilierungsoptionen der fli4l-Pakete irgendwo
nachlesen? Hab mir den Source schon gezogen, aber solche Infos hab ich
bisher nicht gefunden.

MfG Stefan Kresse
Arwin Vosselman
2008-05-23 20:37:43 UTC
Permalink
Hallo Stefan,
Post by Stefan Kresse
Es wurde Internationalisierung eingebaut, aber entsprechende Header
fehlen dem fbr. Wenn ich gettext installiere (hab irgendeine 0.14er
Version drin), dann kompiliert er trotzdem nicht, weil er die wchar.h
und wctype.h nicht findet, obwohl er sie in seinem eigenen Verzeichnis
liegen hat.
Das ist logisch. Bei <filename> wird nur im include-Pfad gesucht. Entweder
. an include-Pfad hinzufügen oder, was Du gemacht hast, den Pfad ohne <>
angeben.
Post by Stefan Kresse
Mich würde am ehesten interessieren, warum die ash aus der busybox die
Umlaute ohne zusätzliche Parameter anzeigt und die von mir kompilierte
Bash (bzw. das ls aus den fileutils) nur mit Parameter.
Kann man die Kompilierungsoptionen der fli4l-Pakete irgendwo
nachlesen? Hab mir den Source schon gezogen, aber solche Infos hab ich
bisher nicht gefunden.
src/buildroot/package/busybox/busybox.config
--
Gruss,
Arwin.
Stefan Kresse
2008-05-23 21:06:11 UTC
Permalink
Post by Arwin Vosselman
Das ist logisch. Bei <filename> wird nur im include-Pfad gesucht. Entweder
. an include-Pfad hinzufügen oder, was Du gemacht hast, den Pfad ohne <>
angeben.
Ja, ein bisschen C-Programmierung kann ich schon, deswegen hatte ich
das versucht ;-).
Die Headerdateien kommen übrigens doch nicht aus dem Paket, ich hatte
die versuchsweise da rein gelegt, in der Hoffnung, es würde helfen...
Kompilieren wird er es wohl trotzdem nicht. Evtl. ist das installierte
gettext zu alt; die neuste Version davon wollte aber nicht kompilieren
*augenroll*. Erinnert irgendwie an SuSE 7.x mit den
Paketabhängigkeiten, die man manchmal manuell auflösen musste...

Deswegen hab ich dann einfach ne ältere Version versucht - mit Erfolg.
Post by Arwin Vosselman
Post by Stefan Kresse
Kann man die Kompilierungsoptionen der fli4l-Pakete irgendwo
nachlesen? Hab mir den Source schon gezogen, aber solche Infos hab ich
bisher nicht gefunden.
src/buildroot/package/busybox/busybox.config
Danke, da hab ich reingeschaut, aber ich finde nichts, was auf
Zeichensatz hindeutet. Die einzige Zeile, die was mit 'Locale' sagt,
ist auskommentiert.

MfG Stefan Kresse

Loading...