Metazeichen in Dateinamen

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.

Linux-User schrieb:

aber teile sie nicht. Es gibt keinen technischen Grund die Dateinamen, abgesehen von 0 und /, zu beschränken.

doch, den gibt es: das Leerzeichen ist in den gängigen Shells Trennzeichen zwischen Argumenten/Listenelementen und gleichzeitig Zeichen in Dateinamen.

Das wäre ungefähr so wie eine Programmiersprache, in deren Befehlsnamen Zeichen vorkommen, die gleichzeitig Trennzeichen oder arithmetische Zeichen wären: PRI-NT, PRI"N"T oder PRI NT. Doch nicht gut, so etwas, ganz prinzipiell.

dabei meine ich mit "Programmiersprache" solche vom klassischen "BASIC"-Typ mit der üblichen Klammer-, Arithmetik- und Stringsyntax - nicht, daß jetzt argumentiert wird, daß in Sprachen wie Forth oder Lisp etliche Befehls- und Funktionsbezeichner Sonderzeichen enthalten. Da ist es ja Ok.

u_ser-l schrieb:

Linux-User schrieb:

aber teile sie nicht. Es gibt keinen technischen Grund die Dateinamen, abgesehen von 0 und /, zu beschränken.

doch, den gibt es: das Leerzeichen ist in den gängigen Shells Trennzeichen zwischen Argumenten/Listenelementen und gleichzeitig Zeichen in Dateinamen.

Das ist richtig, aber so ziemlich das gleiche Problem hast du bei SQL auch und dort muss man genau so Vorkehrungen dagegen treffen.

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.

Übrigens dein zweites Snippet funktioniert bei mir gar nicht, weil ls -R gibt bei mir den Inhalt so aus:

$ cd /tmp
$ mkdir -p test/with/sub/folder
$ touch !$/testfile
$ ls -R test
test:
with

test/with:
sub

test/with/sub:
folder

test/with/sub/folder:
testfile
$

Ich bin darauf gestoßen, weil mir einfiel, dass man das Problem umgehen könnte in dem man nicht ls -R * aufruft, sondern ls -RA ., aber als ich die Ausgabe gesehen habe fiel mir das Problem auf. Ich konnte auch kein Parameter finden der dieses Verhalten in GNU ls ändert.
Ich muss zugeben, dass ich ls -R eigentlich nie benutze, da ich dafür tree benutze:

$ tree test
test
`-- with
    `-- sub
        `-- folder
            `-- testfile

3 directories, 1 file
$

Linux-User schrieb:

Übrigens dein zweites Snippet funktioniert bei mir gar nicht, weil ls -R gibt bei mir den Inhalt so aus:

nein, funktioniert nicht, habe ich doch geschrieben - es sollte illustrieren, daß man mit "for i in ..." nicht weiterkommt, wenn man kompliziertere Listen braucht, als diejenigen, welche * usw. liefern kann. "for i in *" war dein Vorschlag, nicht meiner. "for i in $(ls -R) ..." klappt schon nicht, wenn Leerzeichen in Dateinamen auftreten.

Letztendlich scheint mir folgende Zeile alle erwähnten Probleme zu umschiffen:

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

nötigenfalls mit weiteren Optionen an find: -type f oä