Warum soll für Dateinamen utf-8 festgelegt werden? Ein einheitlicher Zeichensatz wäre in der Tat sehr sehr wichtig, aber warum bloss utf-8? Ich stelle es mir gerade recht schwierig vor, z. B. ein Shellskript zu schreiben, das in irgend einer Weise mit bereits vorhandenen Dateien zu tun hat, wo alle Dateinamen in chinesischen Zeichen gehalten sind.
Hier sollte man sich wirklich auf den kleinsten gemeinsamen Nenner einigen (und auch die Chinesen haben lateinische Buchstaben auf der Tastatur!), und das wäre z. B. einfach dem Vorschlag von POSIX zu folgen, und nur die Buchstaben a-z, A-Z, die Ziffern 0-9, usw.. Es ist auch nicht so, dass diese Zeichen nicht für Dateinamen vollkommen ausreichen würden. (Ich persönlich halte das schon seit Jahren so, ganz ohne diesen POSIX-Vorschlag gekannt zu haben, weil es das einzig sinnvolle ist)
Utf-8 finde ich generell sehr nett, aber doch bitte nur dort, wo es sinnvoll ist.
und setzt eine internationale Normierung voraus, damit das gelöst werden kann.
Der kleinste gemeinsame Nenner wäre: Dateiname maximal 8 Buchstaben, dann ein "." und maximal 3 Buchstaben Erweiterung. Aber dann geht es auch mit Slash / und Slosh \ los. Von den Laufwerksbuchstaben mal ganz abgesehen.
Der kleinste gemeinsame Nenner ist also auch keine Lösung.
Man sollte evtl. http://www.w3.org/Addressing/rfc1738.txt als Basis nehmen.
> Neuere Linux-Distributionen verwenden per Konvention UTF-8, doch wird dies nirgends erzwungen
Aus genau diesem Grund nehme ich JFS für alle Datenpartitionen, denn damit, kann ich UTF8 sehr wohl erzwingen. Leider verliert JFS immer mehr an Unterstützung durch die Distributionen.
Also das mit dem - am Dateinamen verbieten empfinde ich als Unsinn. Unter GNU gibts ja cat -- * und ansonsten kann mann immer noch cat ./* machen. Ist also kein Problem.
Die Steuerzeichen gehörten meiner Meinung nach auch verboten. Eventuell auch newline, denn das macht Probleme wenn man Dateinamen in einer Datei abspeichert, einfach mit ls -1 oder so. Und wenn man wirklich restriktiv sein will dann eventuell auch noch :, weil das der Pfad-Trenner ist. I.d.R. hat man zwar keinen : in seinen Pfad. Aber rein aus Sauberkeits-Gründen ist das nicht gut und kann u.U. auch zu schwereren Problemen führen (falsche Interpretation von $PATH ist ein schweres Problem).
Aber - würde ich nicht verbieten. Auch keine Spaces (aber eben schon Zeilenumbrüche).
Von Benjamin Schweizer am Do, 26. März 2009 um 17:56 #
Die lokale Zeichenkodierung wird vom Admin/der Distribution systemweit eingestellt, dafür gibts die Locales. Das Dateisystem folgt diesem Prinzip. Um hier möglichst alle existierenden Encodings abgebildet zu können, ist Binary eine akzeptierte Lösung (die alternative wäre eine Umwandlung der Zeichen in einen Zeichensatz, der alle Zeichen abbilden kann). Daneben sehe ich es als einen Gewinn an, beliebige Dateinamen verwenden zu können. Bleibt also nur die Sicherheitsproblematik von Shell Skripten. Diese betrifft zunächst das Globbing (Erweiterung von "*" und "?"), sie ist Anwendungsspezifisch und könnte/sollte?/ist?? in der jeweiligen Shell gefixt werden.
Von Crass Spektakel am Fr, 27. März 2009 um 01:27 #
Ok, mal Tachyles:
Mein Amiga 1000 Baujahr 1985 mit 256kByte RAM hat keinerlei Probleme mit Sonderzeichen in Dateinamen, niemals nie nicht. Naja, ausser ich verwende eine CSH anstelle von AmigaOS. Ich kann das gerne jederzeit testen da mein Amiga1000 über NFS mit meinem Unixserver mit Abermillionen Dateien mit wüsten Namen kommuniziert.
Dazu kommt daß Amiga-Shell-Regex weit mächtiger sind als alles was ihr von Unix kennt, gerademal Perl kommt an die Mächtigkeit der Regex von AmigaOS ran, aber nur in der Leistungsfähigkeit aber nicht in der einfachen und generellen Nutzbarkeit - denn sowohl in der Shell klappen Regex aber auch in grafischen Filerequestern. Und das bei schnellerer Behandlung und weniger Speicherverbrauch.
Wie das denn?
Weil bei AmigaOS die Wildcards/Regex NICHT von der Shell aufgelöst werden sondern von der Anwendung unter Nutzung externer Bibliotheken. Ein "list mp3:#?.mp[e|]g[|1|2]" format=filecheck {}" in einem Verzeichnis mit 100.000 MPeg-Dateien ist in so ca. einer halben Minute erledigt und braucht 30kByte. Auf einem Rechner mit 7Mhz Takt.
Unter AmigaOS kann ich über Dateinamen wie --help, /? oder |\/ nur lachen.
Ich habe immer wieder Probleme damit, dass der Slash (/) in Dateinamen nicht erlaubt ist. Damit sind Dateinamen wie "AC/DC - Highway to Hell.ogg" unmöglich, auch viele Texte und einige Filme lassen sich nicht mit ihrem Titel als Dateinamen abbilden.
Ist es nicht möglich, in UTF ein zusätzliches Zeichen "Slash but no path delimiter" zu etablieren, das wie ein Slash dargestellt wird, aber eben nicht wie der "klassische" Slash mit 0x002F kodiert wird?
Wenn Sonderzeichen wie ?, * und so weiter eingeschränkt werden, dann bekommt man die gleichen Probleme wie unter Windows. Wie soll man dann in einer MP3 Sammlung noch zwischen Bands "Stellar" und "Stellar*" unterscheiden? Oder, genauso schlimm, Pinks Floyd, The Wall: "The Thin Ice" und "The Thin Ice?".
Gearde die vergleichsweise grosse Zeichenvielfalt der Linux Dateisysteme ist für mich einer der k.o. Argumente gegenüber anderen Plattformen.
Die oben genannten Probleme, kennt ja fast jeder, der schonmal ein bisschen mit der Shell geskriptet hat etc. Aber das finde ich auch die nervigste Schwäche der Shell: Obwohl sie schon eine SKriptsprache ist, mir der man rein technisch bedingt viel mit Zeichenketten zu tun hat, ist das String-handling absolut grottig! Da ich kein Shell-Guru bin, dreht sich bei jedes mal der Magen um, wenn ich Dateien greppen muss, und dann aber nach Sonderzeichen suche... Das geht einfach mal garnicht so...
Warum nicht einfach so wie unter Windows? Anführungszeichen drum und gut is - übrigens macht die Autocompletion in der Windowsshell schon automatisch Anführungszeichen drum.
Bash und Co. sind zwar schön und gut aber brauchen dringend nochmal eine Generalüberholung. Letztendlich ist ja Perl auch nur entwickelt worden, weil die Shell zu unzulänglich geworden ist. Leider hatte die Shell nie nachgezogen...
Hier sollte man sich wirklich auf den kleinsten gemeinsamen Nenner einigen (und auch die Chinesen haben lateinische Buchstaben auf der Tastatur!), und das wäre z. B. einfach dem Vorschlag von POSIX zu folgen, und nur die Buchstaben a-z, A-Z, die Ziffern 0-9, usw.. Es ist auch nicht so, dass diese Zeichen nicht für Dateinamen vollkommen ausreichen würden. (Ich persönlich halte das schon seit Jahren so, ganz ohne diesen POSIX-Vorschlag gekannt zu haben, weil es das einzig sinnvolle ist)
Utf-8 finde ich generell sehr nett, aber doch bitte nur dort, wo es sinnvoll ist.
damit das gelöst werden kann.
Der kleinste gemeinsame Nenner wäre:
Dateiname maximal 8 Buchstaben, dann ein "." und maximal 3 Buchstaben Erweiterung.
Aber dann geht es auch mit Slash / und Slosh \ los.
Von den Laufwerksbuchstaben mal ganz abgesehen.
Der kleinste gemeinsame Nenner ist also auch keine Lösung.
Man sollte evtl.
http://www.w3.org/Addressing/rfc1738.txt
als Basis nehmen.
Ich werd mich jedenfalls daran orientieren.
Aus genau diesem Grund nehme ich JFS für alle Datenpartitionen, denn damit, kann ich UTF8 sehr wohl erzwingen. Leider verliert JFS immer mehr an Unterstützung durch die Distributionen.
Die Steuerzeichen gehörten meiner Meinung nach auch verboten. Eventuell auch newline, denn das macht Probleme wenn man Dateinamen in einer Datei abspeichert, einfach mit ls -1 oder so. Und wenn man wirklich restriktiv sein will dann eventuell auch noch :, weil das der Pfad-Trenner ist. I.d.R. hat man zwar keinen : in seinen Pfad. Aber rein aus Sauberkeits-Gründen ist das nicht gut und kann u.U. auch zu schwereren Problemen führen (falsche Interpretation von $PATH ist ein schweres Problem).
Aber - würde ich nicht verbieten. Auch keine Spaces (aber eben schon Zeilenumbrüche).
Bleibt also nur die Sicherheitsproblematik von Shell Skripten. Diese betrifft zunächst das Globbing (Erweiterung von "*" und "?"), sie ist Anwendungsspezifisch und könnte/sollte?/ist?? in der jeweiligen Shell gefixt werden.
Mein Amiga 1000 Baujahr 1985 mit 256kByte RAM hat keinerlei Probleme mit Sonderzeichen in Dateinamen, niemals nie nicht. Naja, ausser ich verwende eine CSH anstelle von AmigaOS. Ich kann das gerne jederzeit testen da mein Amiga1000 über NFS mit meinem Unixserver mit Abermillionen Dateien mit wüsten Namen kommuniziert.
Dazu kommt daß Amiga-Shell-Regex weit mächtiger sind als alles was ihr von Unix kennt, gerademal Perl kommt an die Mächtigkeit der Regex von AmigaOS ran, aber nur in der Leistungsfähigkeit aber nicht in der einfachen und generellen Nutzbarkeit - denn sowohl in der Shell klappen Regex aber auch in grafischen Filerequestern. Und das bei schnellerer Behandlung und weniger Speicherverbrauch.
Wie das denn?
Weil bei AmigaOS die Wildcards/Regex NICHT von der Shell aufgelöst werden sondern von der Anwendung unter Nutzung externer Bibliotheken. Ein "list mp3:#?.mp[e|]g[|1|2]" format=filecheck {}" in einem Verzeichnis mit 100.000 MPeg-Dateien ist in so ca. einer halben Minute erledigt und braucht 30kByte. Auf einem Rechner mit 7Mhz Takt.
Unter AmigaOS kann ich über Dateinamen wie --help, /? oder |\/ nur lachen.
Ist es nicht möglich, in UTF ein zusätzliches Zeichen "Slash but no path delimiter" zu etablieren, das wie ein Slash dargestellt wird, aber eben nicht wie der "klassische" Slash mit 0x002F kodiert wird?
Gearde die vergleichsweise grosse Zeichenvielfalt der Linux Dateisysteme ist für mich einer der k.o. Argumente gegenüber anderen Plattformen.
R
Warum nicht einfach so wie unter Windows? Anführungszeichen drum und gut is - übrigens macht die Autocompletion in der Windowsshell schon automatisch Anführungszeichen drum.
Bash und Co. sind zwar schön und gut aber brauchen dringend nochmal eine Generalüberholung. Letztendlich ist ja Perl auch nur entwickelt worden, weil die Shell zu unzulänglich geworden ist. Leider hatte die Shell nie nachgezogen...