Metazeichen in Dateinamen

mal eine grundlegende Frage:

Aus welchem Grund hat man angefangen, Metazeichen (speziell Leerzeichen, aber auch $, * usw.) in Dateinamen zuzulassen?

Es muß doch klar gewesen sein, daß vieles verkompliziert wird [" $@" "$ " $@ $ und -print0 lassen grüßen ... ], wenn man bspw. Leerzeichen in Dateinamen zuläßt, sodaß die Kommandozeile beim Interpretieren eines Leerzeichen nicht weiß, ob es sich um die Abtrennung zwischen Argumenten handelt, um Trennzeichen zwischen Listenelementen, oder um Leerzeichen inmitteln von Dateinamen.

Zwangsläufige Folge sind kryptische Work-arounds mit "...", "$@" und '\ ' usw. in Shellskripten an allen Ecken und Enden.

Wieso reicht im Deutschen und Englischen der Zeichenvorrat a-zA-Z0-9_- nicht aus, um daraus alle Dateinamen zusammenzusetzen?

general bacardi

u_ser-l schrieb:

Aus welchem Grund hat man angefangen, Metazeichen (speziell Leerzeichen, aber auch $, * usw.) in Dateinamen zuzulassen?

Das sind keine "Metazeichen" sondern ganz normale. Solange keine binäre Null in Dateinamen erscheit, ist alles in Ordnung. Wer Ende von Dateinamen an Leerzeichen erkennen will, hat selber Schuld :p

isabeau

Der Durchschnitts-Computer-Benutzer, der seinen Rechner "Heikes Computer" nennt und seine Dateien unter "Dokumente und Einstellungen", speziell aber unter "Eigene Dateien", ablegt, braucht eben auch Leerzeichen im Dateinamen: "Tante Erwin.bmp"

general bacardi schrieb:

Das sind keine "Metazeichen" sondern ganz normale.

Du weißt, was "Metazeichen" bedeutet? "Zeichen mit Sonderbedeutung". Für die Bash sind das *, $, ? und viele weitere. Ich plädiere dafür, keine Metazeichen in Dateinamen zu verwenden.

general bacardi schrieb:

Solange keine binäre Null in Dateinamen erscheit, ist alles in Ordnung. Wer Ende von Dateinamen an Leerzeichen erkennen will, hat selber Schuld :p

so einfach ist das in C/C++, so einfach ist das aber nicht überall Die bash z.B. trennt Kommandozeilenargumente und Listen durch Leerzeichen. Es gibt work-arounds, wie "$@" oder find -print0, schön ist das nicht.

Bashar

Was interessiert es das Betriebssystem, was irgendeine Shell für Metazeichen hält? Da sollen sich die Shells und ihre Benutzer mal schön selbst drum kümmern, dass sie das geregelt kriegen.

general bacardi

u_ser-l schrieb:

Die bash z.B. trennt Kommandozeilenargumente und Listen durch Leerzeichen. Es gibt work-arounds, wie "$@" oder find -print0, schön ist das nicht.

Das ist aber ein Fehler der Bash. Ist Open Source, du kannst es ändern

u_ser-l schrieb:

Ich plädiere dafür, keine Metazeichen in Dateinamen zu verwenden.

Ich plädiere für ein Dateisystem, das nicht künstlich limitiert ist, nur um diversen broken-by-design shells zu genügen.

Daß Leerzeichen die Kommandozeilenargumente abtrennen, ist ja kein Fehler der bash, sondern ein Feature - so kann man bequem schreiben:

rm foo1 foo2 foo3

Gut, man könnte die Shell so abändern, daß ein anderes Zeichen die Argumente trennt, etwa §, dann müßte man schreiben

rm foo1§foo2§foo3

und verlangen, daß Dateinamen kein § enthalten. Ob damit viel gewonnen ist ?

Da scheint mir doch sinnvoller, Dateinamen auf a-zA-Z0-9_-. einzuschränken (und für andere Sprachen auf entsprechende Nicht-Metazeichen in utf-8 o.ä.). Wäre das so eine große Zumutung?

welche Kommandozeile trennt ihre Argumente denn nicht nach Leerzeichen?

man müßte dann sogar schreiben:

rm §foo1§foo2§foo3§

denn schließlich könnte foo3 ja mit einem Leerzeichen enden und foo1 mit einem beginnen.
Gewöhnungsbedürftig.

knivil

Man kann sie escapen, ich sehe da kein Problem. Ausserdem hat z.B. die bash tab completion. Ich bin gegen irgendwelche Limitierungen von Dateinamen.

general bacardi

u_ser-l schrieb:

und verlangen, daß Dateinamen kein § enthalten.

Damit nervst du Anwälte und Richter.

u_ser-l schrieb:

Daß Leerzeichen die Kommandozeilenargumente abtrennen, ist ja kein Fehler der bash, sondern ein Feature - so kann man bequem schreiben:
rm foo1 foo2 foo3

Ja das stimmt. Das ist bequem.

Gut, man könnte die Shell so abändern, daß ein anderes Zeichen die Argumente trennt, etwa §, dann müßte man schreiben
rm foo1§foo2§foo3
und verlangen, daß Dateinamen kein § enthalten. Ob damit viel gewonnen ist ?

Hier stimme ich dir auch zu, das wäre bullshit. Vor allem, weil es dann immer noch ein sonderzeichen gibt, das vom Dateisystem nicht verwendet werden darf.

Da scheint mir doch sinnvoller, Dateinamen auf a-zA-Z0-9_-. einzuschränken (und für andere Sprachen auf entsprechende Nicht-Metazeichen in utf-8 o.ä.). Wäre das so eine große Zumutung?

Und das finde ich doof. Das Dateisystem steht in der Hierarchie deutlich über der Shell, d.h. es ist grundlegender. Anstatt den Namensraum des Dateisystems einzuschränken würde ich lieber Änderungen an der Shell vornehmen.
Die jetzige Lösung -- Escape-Zeichen für alles mögliche zu verwenden -- funktioniert relativ gut, vor allem weil esoterische Zeichen in Dateinamen selten auftreten, und es im Standardfall sehr bequem funktioniert.

Prinzipiell eleganter wäre es, statt den Namensraum des Dateisystems einzuschränken, den Namensraum der Shell zu erweitern. Zum Beispiel könnte man ein neues Trennzeichen einführen (shell separator), das in der Shell als Leerzeichen angezeigt wird, und durch Betätigen der Leertaste eingegeben wird. Möchte man ein 'richtiges' ASCII oder Unicode Leerzeichen eingeben, muss man eine kompliziertere Tastenkombination verwenden; kontext-beachtende Mechanismen wären auch denkbar. Dieses Verfahren wäre angebracht, wenn Leerzeichen in Dateinamen viel öfter auftreten würden.

Letztere Methode -- obwohl mathematisch eleganter -- hat dennoch zahlreiche Probleme. Zum einen ist dann ein shell-skript nicht mehr eine ASCII/Unicode Textdatei sondern ein mehr oder weniger kompatibles Binärformat (da die Sonderzeichen gerade die Bedingung erfüllen müssen, nicht in einem Zeichensatz aufzutreten)
Zweitens ist der Aufwand, eine Shell zu schreiben größer. Deswegen verlassen sich wohl shells größtenteils auf escape- und quote-zeichen-

namespace invader

"Normale Menschen" benutzen ohnehin keine Shell mehr für irgendwas, sondern grafische Dateimanager. Und damit erscheint es sinnfrei, dass man bestimmte Zeichen nicht verwenden können soll.

Es muss ja niemand diese "Metazeichen" verwenden. In bestimmten Bereichen (Quelltexte...) ist es sinnvoll, freiwillig darauf zu verzichten. Aber meine MP3s möchte ich schon gerne mit Leerzeichen benennen können, das ist sonst hässlich.

knivil schrieb:

Man kann sie escapen, ich sehe da kein Problem. Ausserdem hat z.B. die bash tab completion.

das nützt dir aber im Falle von Leerzeichen schon bei

for i in $(ls); do ...; done
for i in $(find .); do ...; done

nichts, und mir geht es hauptsächlich um unschöne work-arounds in Skripten:

ls|while read i; do ...; done
for i in "$@"; do ...; done

das muß konsistenter sein können.

Tom Waits schrieb:

Anstatt den Namensraum des Dateisystems einzuschränken würde ich lieber Änderungen an der Shell vornehmen.

ich habe nichts dagegen, daß das Dateisystem beliebige Bezeichner für file objects zuläßt, das ist ok, für Sonderanwendungen meinetwegen. Nur sollte dem Benutzer weder über Shell noch über Desktop ermöglicht werden, file objects mit kuriosen Sonder- und Metazeichen anzulegen oder zu bearbeiten.

Wer partout Leerzeichen in Dateinamen haben will, sollte im Filebrowser einen Modus anschalten können, der den Unterstrich in Dateinamen als Leerzeichen darstellt, und umgekehrt bei Eingabe von Leerzeichen in Dateinamen automatisch Unterstriche einfügt. Oder meinetwegen Sonderzeichen in Dateinamen alphanumerisch umschreiben, etwa "G_uuml_nter" für "Günter", was durch das GUI transparent umgewandelt werden könnte bei Eingabe bzw. Darstellung.

Ich kenne allerdings keinen zwingenden Grund, Leerzeichen & co. in Dateinamen zu verwenden, und da es im Zweifelsfall stören kann, kann man es doch einfach unterlassen.

u_ser-l schrieb:

Ich kenne allerdings keinen zwingenden Grund, Leerzeichen & co. in Dateinamen zu verwenden, und da es im Zweifelsfall stören kann, kann man es doch einfach unterlassen.

und ich bin dafür, dass man nur zahlen in dateinamen verwenden darf.

namespace invader

Ich bin ganz gegen Dateinamen! Es ist völlig ausreichend, wenn es pro Dateisystem nur 10 hardgecodete Dateien gibt

u_ser-l schrieb:

knivil schrieb:

Man kann sie escapen, ich sehe da kein Problem. Ausserdem hat z.B. die bash tab completion.

das nützt dir aber im Falle von Leerzeichen schon bei
for i in $(ls); do ...; done
for i in $(find .); do ...; done
nichts, und mir geht es hauptsächlich um unschöne work-arounds in Skripten:
ls|while read i; do ...; done
for i in "$@"; do ...; done
das muß konsistenter sein können.

Haha,

so macht man das auch nicht, sondern so:

for in in *; do ...; done

Und für den Rest ist das mit "" kein hässlicher Workaround, sondern es ist der korrekte Weg um Eingaben mit Metazeichen zu verarbeiten. Deine 4 Beispiele oben zeigen mir aber deutlich warum du Probleme hast. Lern erst einmal mit den Tools ordentlich umzugehen bevor du meckern willst.

Linux-User schrieb:

Haha,

so macht man das auch nicht, sondern so:
for in in *; do ...; done

Richtig muss es natürlich heißen:

for i in *; do ...; done

namespace invader schrieb:

Ich bin ganz gegen Dateinamen! Es ist völlig ausreichend, wenn es pro Dateisystem nur 10 hardgecodete Dateien gibt

nimm wenigstens ein byte, dann haste 256 dateinamen. aber das dürfte u_ser-l wieder nicht gefallen, weil ja metazeichen auftauchen können.

Linux-User schrieb:

Haha, so macht man das auch nicht, sondern so:
for in in *; do ...; done

Na und? Das ändert gar nichts an der Sachlage - der Stern funktioniert in diesem trivialen Fall, aber zeig' mir mal, wie du damit

ls -R|while read i; do ...; done

löst ...

for in in *; do ...; done

soviel zum Thema "tools beherrschen lernen"