Metazeichen in Dateinamen

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.

u_ser-l schrieb:

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

ARG_MAX hat in dem Fall keine Wirkung, da for ein shell built-in ist, das heißt es wird kein Prozess mit diesen Parametern aufgerufen.

Deine Beispiele sind nicht identisch mit meinem, bei meinem wird zur Terminierung eines Dateifpades die ASCII-Null verwendet und sonst nichts, das ist das einzige Zeiche bei dem du dich darauf verlassen kannst, dass es nicht im Pfad vorkommt (und Dateinamen dürfen keinen Slash enthalten).

ich beneide dich um deine wissensmäßigen Entwicklungsmöglichkeiten ...

Solange du dieses Potential noch nicht ausgeschöpft hast, empfehle ich dir einen angemessenen Diskussionsstil.

Thema der Debatte ist nicht, wie man in der bash Leerzeichen in Dateinamen behandelt (da hätte ich von dir ohnehin nichts zu lernen), sondern wieso Leer- und Sonderzeichen zulässig und ob überhaupt notwendig sind.

und was ARG_MAX betrifft:

for i in *; do ...; done

dieser Fall ist tatsächlich unabhängig, aber mit diesem Spezialfall ist es meistens
nicht getan -

for i in $(ls -R *); do ...; done

das funktioniert nicht mit Leerzeichen und ist von ARG_MAX betroffen.

u_ser-l schrieb:

und was ARG_MAX betrifft:
for i in *; do ...; done
dieser Fall ist tatsächlich unabhängig, aber mit diesem Spezialfall ist es meistens
nicht getan -
for i in $(ls -R *); do ...; done
das funktioniert nicht mit Leerzeichen und ist von ARG_MAX betroffen.

Du hast mich offensichtlich falsch verstanden. Deine Problematik habe ich schon erkannt, aber teile sie nicht. Es gibt keinen technischen Grund die Dateinamen, abgesehen von 0 und /, zu beschränken.
Die Shells arbeiten mit Substitution (wie du sicher weißt) und daher sind die Quotes eben notwendig. So wie du auch sonst Benutzereingaben validieren, oder escapen musst. Sehe hier jetzt wirklich nicht dein Problem.

Dein unteres Beispiel benutzt ja schon wieder ls, ls solltest du in einem Shell-Skript nicht benutzen (in Wegwercode ist natürlich alles egal). Für eine Dateiliste ist find, wie oben gezeigt, die richtige Wahl

Und ein anderer Punkt: selbst wenn wir ab jetzt sagen, dass nur diese Zeichen benutzen, aber (aus welchem Grund auch immer) Dateien auf der Festplatte mit ungültigen Dateinamen sind (also z.B. ein Fragezeichen enthalten), was dann? Hatte unter Windows neulich was tolles: eine Datei mit einem | Symbol drin, die konnte der Explorer fröhlich anzeigen, aber löschen ging nicht, auch nicht in der Konsole mit den alten DOS-Dateinamen (FOOBARZZ~1). Also sollte das Betriebssystem Dateinamen nicht künstlich beschränken, aber dann sind plötzlich wieder alle Shells anfällig für exotische Dateinamen, wenn sie sich nicht davor schützen.