Markus Wolf schrieb:
> Hallo Patrick,
>
>> for i in $(find .); do
>> name=$(basename $i)
>> [ ${#name} -gt 10 ] && echo $i
>> done
>>
>
> Jochen's Lösung ist schön kurz (++), aber:
>
>> for i in $(find .); do
>
> wenn das 'inline' expandiert wird, also $(find .) durch ./a ./a/b.txt
> .. ersetzt wird, kann es bei vielen Dateien zu Fehlern kommen (hatte
> ich mal, ist das noch so?). Die Lösung mit find | while read ist
> dagegen sicherer, aber wohl auch langsamer :-))
>
> name=$(basename $i) => name=$(basename "$i");
>
> (${#name} vielleicht auch) Aus dem Kopf, also vorsicht,
>
> Grüsse markus
>
> -- Martin, wo ist die Perl-Lösung ? :-))
Okay, ein
find . | while read; do name=$(basename "$REPLY"); echo ${#name}; done
macht alles wie erwartet (die Längenprüfung usw. lasse ich der Übersicht
halber mal weg). Wichtig sind hierbei nur die " für $REPLY.
Eine generelle Frage die sich mir dabei allerdings stellt ist, in wie
weit read buffert. Ich stelle mir gerade das Szenario vor, dass das was
innerhalb des Loops passiert evtl. mal ganz ganz lange dauern könnte.
Die Ausgabe von find läuft aber derweil schön weiter. Oder wird die
Ausgabe verzögert?
Im Beispiel von Jochen ist der Ablauf etwas anders, dort läuft zunächst
find vollständig durch bis der Rest des Loops aktiv wird.
Sehe ich das richtig?
Oder sind meine Befürchtungen grundlos?
Kann das was verloren gehen?
Mein fertiges Skript sieht nun so aus:
#!/bin/bash
for x
do
find $x | while read
do
name=$(basename "$REPLY")
[ ${#name} -gt 31 ] && echo $i
done
done
Wen es interessiert: Unter MacOS 9 und X, die ein älteres AFP sprechen
als 3.1 kann AFP nur Dateien mit maximal 31 Zeich darstellen.
--
Gruß
Patrick
-=> Verstehe die Technik und Du findest einen Weg sie zu umgehen <=-
--
----------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org