Metazeichen in Dateinamen

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"

außerdem fällt mir gerade ein ...

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

Ihr sollt eure Quellcodes nicht im Dateinamen speichern.

Also ich finde, die Zeichen a-zA-Z0-9_-. sind absolut ausreichend, einen geeigneten Dateinamen zu finden. Warum muss man es sich unnötig schwerer machen? Nur weils möglich ist?

u_ser-l schrieb:

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).

Allgemein solltest du dich mal auf http://mywiki.wooledge.org/ umschauen, da findest du tonnenweise Pitfalls wie sie ständig gemacht werden und dazu wie man es richtig macht. Jeder fängt mal klein an

Linux-User schrieb:

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

du willst dich ja nur rausreden, weil dein for i in * ... schon bei ls -R versagt

[quote="Linux-User"]
Versuch es doch mal mit

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

auf die Möglichkeit "find | -print0" habe ich in einem meiner ersten Posting selbst hingewiesen, wieso verkaufst du mir das jetzt wieder?

Jedenfalls deutlich komplizierter als meine Version, und einen Vorteil hat das -print0 auch nicht.

Da ist meine Version aber deutlich eleganter:

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

Linux-User schrieb:

Wenn man sich halt selber gerade ordentlich auf die Fresse gelegt hat muss man wohl nach jedem Strang greifen

keine Ahnung was du da schreibst - meine Version

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

ist korrekt und elegant - du hast jetzt schon zwei fehlerhafte aufgezählt, wovon ich auf die zweite selbst hingewiesen hatte, und willst mir attestieren, ich könnte nicht mit der bash umgehen ?

Linux-User schrieb:

Dein Argument weiter unten ist übrigens auch schwachsinn, der einzige limitierende Faktor ist dabei der verfügbare Arbeitsspeicher.

Vorsicht, schon mal was von ARG_MAX gehört?

getconf ARG_MAX

nman

Ich weiß, dass find hässlich sein kann, aber mit man: find(1) (-exec, nicht -print) und xargs lässt sich eigentlich eine Menge machen.

Natürlich können Leerzeichen udgl. in Dateinamen lästig sein, aber es zwingt Dich ja niemand dazu, welche zu verwenden. Die meisten Menschen sehen es als großen Fortschritt, dass sie Ihre Dateien nicht mehr "brfkoehl.doc" nennen müssen, sondern diese auch "Brief an Dr. Köhler.doc" heißen dürfen. Ist doch eine feine Sache, auch wenn meine Nomenklatur anders aussieht.