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?

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

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.

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

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.

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?

rm §foo1§foo2§foo3§

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

und verlangen, daß Dateinamen kein § enthalten.

Damit nervst du Anwälte und Richter.

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-

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.

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.

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.

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.

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.

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

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.

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"

Linux-User schrieb:

Haha,

so macht man das auch nicht, sondern so:

for in in *; do ...; done

nein, deine Version kann sogar mit der Fehlermeldung "Argument list too long" abbrechen, wenn bestimmte systemabhängige Grenzen überschritten werden.

Meine Version hat dieses Problem nicht:

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

(ein work-around ist es trotzdem)

Linux-User schrieb:

Deine 4 Beispiele oben zeigen mir aber deutlich warum du Probleme hast. Lern erst einmal mit den Tools ordentlich umzugehen

siehe oben

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,

Doch tut es, weil du offensichtlich nicht davon gewusst hast und dich jetzt rausreden willst. Dein Argument weiter unten ist übrigens auch schwachsinn, der einzige limitierende Faktor ist dabei der verfügbare Arbeitsspeicher.

aber zeig' mir mal, wie du damit

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

löst ...

Sorry, aber ich habe nicht nur einen Hammer, sondern einen ganzen Werkzeugkasten und benutze daher das richtige Tool für den richtigen Job.
Versuch es doch mal mit

find . -type f -print0 | while IFS= read -r -d '' filename; do
  ...
done

for in in *; do ...; done

soviel zum Thema "tools beherrschen lernen"

Wenn man sich halt selber gerade ordentlich auf die Fresse gelegt hat muss man wohl nach jedem Strang greifen
(dumm nur, dasss ich 2Stunden vor deinem Posting bereits auf den Flüchtigkeitsfehler hingewiesen habe, im Gegensatz zu deinen massiven Verständnisfehlern).