staging.inyokaproject.org

Kleine Änderungen:

* Ein STARTPUNKT ist eine existierende Datei (möglich, aber selten sinnvoll) oder im Regelfall ein existierender Ordner in der Dateihierarchie zum Zeitpunkt des Aufrufs. Man kann einen oder auch mehrere Startpunkte angeben, die dann nacheinander abgearbeitet werden. Das Programm untersucht alle Dateien ab jedem angegebenen Startpunkt und bei Ordner auch rekursiv alle enthaltenen Dateien. Wenn man keinen Startpunkt angibt, gilt das aktuelle Arbeitsverzeichnis als Startpunkt.

Es kommt mir abwegig vor, dass jmd. auf die Idee kommen könnte, als Startpunkt eine nicht existierende Datei zu wählen. Analog beim Ordner. Ebenso "zum Zeitpunkt des Aufrufs" - ehm, ja, nicht 1992 oder 2090.

Übersehe ich hier Missverständliches? Überarbeitet:

* Ein STARTPUNKT ist im Regelfall ein Ordner in der Dateihierarchie, andere Dateiformen sind möglich, aber selten sinnvoll. Man auch mehrere Startpunkte angeben, die dann nacheinander abgearbeitet werden. Das Programm untersucht alle Dateien ab jedem angegebenen Startpunkt und bei Ordnern auch rekursiv alle enthaltenen Dateien. Wenn man keinen Startpunkt angibt, gilt das aktuelle Verzeichnis als Startpunkt.

Den Ordner, also den Regelfall, habe ich im Satz vorgezogen.

Dass die Startpunkte nacheinander abgearbeitet werden - ist das ein POSIX-Standard, oder könnten die nicht ab morgen auch parallel abgearbeitet werden?

Beim nächsten Absatz missfiel mir, dass von "eventuellen Optionen" gesprochen wird. Der Begriff Option drückt das optionale bereits aus:

Startpunkte geben an, wo gesucht wird, nicht was gesucht wird. Ist keiner angegeben wird im aktuellen Verzeichnis gesucht. Startpunkte müssen nach eventuellen Optionen und vor den ebenfalls optionalen Suchkriterien und Aktionen platziert werden.

UlfZibis schrieb:

user_unknown schrieb:

Wenn man nicht in die Verzeichnisse absteigt, wozu dann find?

Weil ich dann ein Skript schreiben müsste, was ich mir ersparen wollte.

Was ist für Dich das Kriterium, ob es ein Script ist?

Die Länge?

1
2
3

find *.jpg -exec convert {} -quality 80% klein/{} \; -exec touch -r {} klein/{} \; 
# Die Forschleife gewinnt um 2 Bytes: 
for f in *.jpg; do convert $f -quality 80% klein/$f; touch -r $f klein/$f; done

Außerdem wollte ich das in mehreren Verzeichnissen anwenden. Dann hätte ich das Skript immer wieder verschieben müssen und am Schluss müsste ich dran denken, es im Daten-Verzeichnis auch wieder zu löschen.

Nein, hättest Du nicht verschieben müssen. Und löschen auch nicht.

Ja so gibt es "viele Wege nach Rom" und der mittels find ist einer davon. Die Befehlszeile habe ich automatisch in der bash-Historie,

Gilt für die Forschleife genauso.

brauche dann keinen Editor zur Verbesserung

dito

und kann es nach Verzeichniswechsel dort direkt wieder verwenden, ja sogar Tage später noch.

dito

Für das Skript müsste ich mir einen Ablageort suchen.

Nein. Aber Du könntest. ~/bin ist ein guter Default.

Außerdem bin ich im Skripten nicht so fit, sodass ich dann immer erst auch noch den passenden Artikel suchen muss, der bekanntlich ziemlich länglich ist.

Skripte und find sind nicht disjunkt zueinander. Skripte können find enthalten und find kann Scripte aufrufen.

Außerdem vergesse ich immer wieder die genaue Syntax für den She-Bang.

Dann mach Dir eine muster.sh in ~/bin, die den Shebang schon enthält, und speicher die unter jeweils neuem Namen.

Hier auch.

 # orig: find */01*.mp3 -print -exec sh -c 'mediainfo "{}" | grep "^Bit rate"' \; 

Damit geht auch das Absteigen in Verzeichnisse.

Das dritte wohl auch.

Könnte man etwas einfacher machen, indem man gleich lame statt ffmpeg verwendet:

find *.flac -print -exec bash -c 'read x<<<"{}"; lame -V2 "$x" "${x/%.flac/.mp3}" && touch -r "$x" "${x/%.flac/.mp3}"' \; 

Das ist dann auch gleich ein Beispiel, wie man Shellbefehle in find ... -exec verwendet. So eines fehlte IMHO im Artikel.

IMHO nicht, weil man nicht jeden Aspekt, den man bei der Verwendung von x oder y mit find beleuchten kann, erklären kann.
Für Shellbefehle gilt nichts Besonderes, was nicht ohne find für Shellbefehle ohnehin gilt.

Aber wo wir gerade dabei sind ... wie kann man denn das vorangestellte "./" im Ergebnis von find vermeiden, wenn man die Option -name verwendet? So einen Hinweis fände ich ziemlich nützlich für den Artikel.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Noch mit Punkt, Ausgangssituation: 
stefan@t530:~/dl$ find  -name "*pdf" -size -5k
./xpdf-4.03/xpdf
./xpdf-4.03/build/xpdf
# Absoluter Pfad: 
stefan@t530:~/dl$ find $PWD -name "*pdf" -size -5k
/home/stefan/dl/xpdf-4.03/xpdf
/home/stefan/dl/xpdf-4.03/build/xpdf
# Punkt-Slash mit Sed durch nichts substituieren, wenn es am Zeilenanfang (^) steht:
stefan@t530:~/dl$ find -name "*pdf" -size -5k | sed 's/^.\///' 
xpdf-4.03/xpdf
xpdf-4.03/build/xpdf
# printf verwenden:
find -name "*pdf" -size -5k -printf "%P\n" 
xpdf-4.03/xpdf
xpdf-4.03/build/xpdf

Ist da was für Dich dabei?

user_unknown schrieb:

Das Kürzen von Shellbefehl findet meine uneingeschränkte Zustimmung.

Besser wäre vielleicht sogar hier "Programm" zu verwenden, da mit -exec ja Programme direkt aufgerufen werden, ohne Shell.

Ja.

user_unknown schrieb:

Es kommt mir abwegig vor, dass jmd. auf die Idee kommen könnte, als Startpunkt eine nicht existierende Datei zu wählen. Analog beim Ordner.

👍 Also:

• ein existierender STARTPUNKT ist eine existierende Datei \ Ordner

• ein STARTPUNKT ist eine Datei \ Ordner

🤣

Überarbeitet:
...
Den Ordner, also den Regelfall, habe ich im Satz vorgezogen.

Finde ich sehr gelungen. 👍

Dass die Startpunkte nacheinander abgearbeitet werden - ist das ein POSIX-Standard, oder könnten die nicht ab morgen auch parallel abgearbeitet werden?

Nacheinander heißt ja nicht "genau in der Reihenfolge". Zumindest die Ausgabe im Terminal erfolgt nacheinander und nicht parallel. Statt "nacheinander" wäre "separat" vielleicht zutreffender, klingt aber eher gestelzt. Und das mit dem "parallel" ist im Regelfall nicht wirklich zutreffend, denn wirklich parallele Verarbeitung geht erst mal nur auf Mehrkernsystemen, bei 4 Kernen also maximal 4 Dinge echt parallel. Alles andere ist nur quasi-parallel.

Beim nächsten Absatz missfiel mir, dass von "eventuellen Optionen" gesprochen wird. Der Begriff Option drückt das optionale bereits aus:

Wo er recht hat, hat er Recht. Genau genommen geht es hier um "eventuelle Schalter", die ggf. die ohnehin gegebenen Optionen aktivieren oder eben nicht. Also

... Startpunkte müssen nach eventuellen Optionsschaltern und vor den ebenfalls optionalen Suchkriterien und Aktionen platziert werden.

Wenn man die Sprache präzise genau anwenden will, kann's länglich werden, siehe: https://www.youtube.com/watch?v=b65CWhmJuyQ
Aber ich denke, dass mit "eventuellen Optionen" der übliche Sprachgebrauch schon ganz gut getroffen wird.

user_unknown schrieb:

Was ist für Dich das Kriterium, ob es ein Script ist?

[.....]

Ich kann Deiner ausführlichen Argumentation nicht widersprechen und danke für Deine Tipps. Ich folge da halt auch einem "Gefühl", genährt aus der Erfahrung, dass das "ich mach' mir mal schnell ein Skript" sehr oft zu quälenden Recherchen in Shell/Bash-Skripting-Guide für Anfänger (und oft fehlt auch da was) führte, bis ich endlich hatte, was ich brauchte. Da reize ich doch lieber erst mal die Möglichkeiten von find aus.

IMHO nicht, weil man nicht jeden Aspekt, den man bei der Verwendung von x oder y mit find beleuchten kann, erklären kann.
Für Shellbefehle gilt nichts Besonderes, was nicht ohne find für Shellbefehle ohnehin gilt.

In meinen 3 Beispielen zeige ich folgendes:

• "Missbrauch" des Startpunkts als Suchkriterium (im aktuellen und auch Unterverzeichnis), um "./" zu vermeiden. (Diesen Trick findet man zu Hauf im Netz, wenn man Beispiele zu find sucht, nur leider nicht in diesem Artikel, obwohl das gängige Praxis zu sein scheint.)

• einfaches Verketten von mehreren -exec-Aktionen

• Verketten mittels &&, | und <<< etc.

• Abwandlung der durch find gefundenen Strings

• Einbettung von Skript-Syntax allgemein

• Hinweis, dass dann {} von " umschlossen werden muss

• Setzen und Verwenden von Variablen im -exec-Ausdruck

Natürlich hätte ich das da auch alles detailliert beschreiben können, doch wollte ich Überladung vermeiden und habe mich so auf das wichtigste beschränkt und dem interessierten Leser die genauere Analyse der "Tricks" überlassen.

Ist da was für Dich dabei?

Ja interessant, Danke! Das mit dem $PWD ist auf jeden Fall eine Lösung. Die sed-Lösung hilft aber nicht, wenn man das Ergebnis davon z.B. mittels klein/{} in find ... -exec weiterverwenden will. Aber eigentlich hoffte ich, dass find selbst eine mir bisher verborgene Möglichkeit bietet, "./" zu vermeiden. Wird doch bestimmt öfter so gewünscht sein.

UlfZibis schrieb:

Für Shellbefehle gilt nichts Besonderes, was nicht ohne find für Shellbefehle ohnehin gilt.

In meinen 3 Beispielen zeige ich folgendes:

• "Missbrauch" des Startpunkts als Suchkriterium (im aktuellen und auch Unterverzeichnis), um "./" zu vermeiden. (Diesen Trick findet man zu Hauf im Netz, wenn man Beispiele zu find sucht, nur leider nicht in diesem Artikel, obwohl das gängige Praxis zu sein scheint.)

Ich weiß nicht, wieso man ./ vermeiden will/sollte.

Um zu vermeiden, dass die Thumbnails in klein/ wieder verkleinert werden kann man -maxdepth verwenden:

1

find -maxdepth 1 -name "*.png" -exec convert {} -quality 80% klein/{} \; -exec touch -r {} klein/{} \; 

oder "klein" ausschließen:

1

find -not -path "*klein*" -name "*.png" -exec convert {} -quality 80% klein/{} \; -exec touch -r {} klein/{} \;

• einfaches Verketten von mehreren -exec-Aktionen

Ja, das Beispiel ist plausibel. Ich würde dann aber noch dazuschreiben, dass erst eine Verkleinerung des Bildes erzeugt wird, und dieses auf das gleiche Dateidatum gesetzt wird, wie das Original - nicht jeder kennt sich mit touch aus.

• Verketten mittels &&, | und <<< etc.

Wenn man nicht zwischendurch weitere find-Filter einbaut, dann finde ich es einfacher, ein ad-hoc-Script zu schreiben:

1
2
3
4
5

#!/bin/bash
#
# adhoc.sh
#
mediainfo "$1" | grep "^Bit rate"

und dann

1

find -name "*.mp3" -print -exec ./adhoc.sh {} \; 

aufzurufen.

Dass im gleichen Zug wieder die Startparameter als Suchmuster eingesetzt werden, und dann auch noch mit 01 beginnen sollen, ist m.E. over the top. Typischerweise sucht man mit find nun mal rekursiv und würde eine Schleife für so was nutzen - Dein Vorgehen ist zwar für Dich schlüssig, aber nicht für die Allgemeinheit zu empfehlen.

Wenn man für 1000 PDFs in einem Monsterverzeichnis nur die 5 PDFs bearbeiten will, die diversen find-Kriterien entsprechen, beispielsweise -size -10k -size +5k, dann ist das ein nützlicher Trick, der aber nicht mit -exec verquickt werden sollte, da er orthogonal dazu ist. Man kann Shellbefehle ohne Startpunkt=-type f (ordinäre Datei) benutzen und Startpunkte filtern ohne -exec-Varianten filtern.

• Abwandlung der durch find gefundenen Strings

Mit Strings meinst Du Dateinamen?

• Einbettung von Skript-Syntax allgemein

Skripte lassen sich ohne find besser testen und korrigieren, finde ich. Da kann man auch shellcheck drüber laufen lassen und das find-Kommando wird dann kürzer.

• Hinweis, dass dann {} von " umschlossen werden muss

• Setzen und Verwenden von Variablen im -exec-Ausdruck

Um zu verstehen, was das 3. Beispiel macht, muss ich wieder mitbekommen und erraten, wieso Du nicht nach -name "*.flac" suchst, das .flac-Format kennen, ffmpeg mit dieser lustigen Syntax kennen (-c:v -wtf!) – der Artikel soll Hürden abbauen, nicht aufbauen! ☺

1
2
3
4
5
6

find *.flac -print \
  -exec bash -c '
     read x<<<"{}" 
     ffmpeg -i "$x" -q 2 -c:v copy "${x/%.flac/.mp3}" 2>/dev/null && 
     touch -r "$x" "${x/%.flac/.mp3}" 
  ' \;

Natürlich hätte ich das da auch alles detailliert beschreiben können, doch wollte ich Überladung vermeiden und habe mich so auf das wichtigste beschränkt und dem interessierten Leser die genauere Analyse der "Tricks" überlassen.

Ja, das könntest Du als Quiz aufbereiten und dann in "Shell & Programmieren" als kleine Serie aufziehen. ☺

Jetzt muss ich aber zum Grillen!

user_unknown schrieb:

Ohne eine empirische Untersuchung dazu zu kennen wage ich die Behauptung, dass >90% der Benutzer die Optionen -HLPD0 noch nie benutzt haben, so dass man, wenn man die Manpage liest, ermüdet und irritiert ist, bevor man sich seinem Thema auch nur genähert hat.

Didaktisch hätte ich es für besser gehalten, -HLDP0 gar nicht oder erst gegen Ende und dann knapp zu erwähnen, damit diejenigen, die mit Wiki UND man arbeiten, eine Erklärung für die Diskrepanz finden.

👍

... Da geht es aber schon los mit den Fallstricken. Ein -size 1M ist nicht das gleiche wie -size 1000k usw.
Wenn wir die häufigsten Fallstricke im Artikel haben, dann können wir bei Fragen auf den Artikel verweisen und müssen nicht zig mal die gleiche Antwort geben. Allerdings muss der Artikel auch möglichst einfach verständlich geschrieben sein, damit die Leute nicht die Augen verdrehend das Weite suchen.

👍

user_unknown schrieb:

Ich weiß nicht, wieso man ./ vermeiden will/sollte.

Hm, folgendes funktioniert zu meiner Überraschung tatsächlich:

convert -quality 80% ./Front.jpg q80/./Front.jpg 

... ich hatte aber mal Fälle, wo das zu Problemen führte, ich "schwöre", kann mich beim besten Willen aber nicht mehr erinnern.
Zumindest sieht es hässlich aus.

Um zu vermeiden, dass die Thumbnails in klein/ wieder verkleinert werden

An das Problem hatte ich dabei gar nicht gedacht 💡

kann man -maxdepth verwenden:

... vergrößert den Rechercheaufwand UND die Tipp-Arbeit aber nochmals. Vermutlich ist der Startpunkt-Trick deshalb so beliebt.

... Ich würde dann aber noch dazuschreiben, dass erst eine Verkleinerung des Bildes erzeugt wird, und dieses auf das gleiche Dateidatum gesetzt wird, wie das Original - nicht jeder kennt sich mit touch aus.

Dann müsste ich aber auch grep und | erklären. Ich denke, bis an diese Stelle dringen nur erfahrenere User vor. Denen kann man zumuten, nach touch selbst zu suchen, falls sie das wirklich nicht kennen. Ich will das nicht überladen, es geht nur um ein exemplarisches Beispiel zur einfachen Verkettung.
... und im 3. Beispiel habe ich die Funktion ja dennoch (indirekt) erklärt.

• Verketten mittels &&, | und <<< etc.

Wenn man nicht zwischendurch weitere find-Filter einbaut, dann finde ich es einfacher, ein ad-hoc-Script zu schreiben:

Damit sind wir aber dann wieder bei all den schon erwähnten unangenehmen Erfahrungen und Aufwand, die ich mit "mal schnell ein Skript schreiben" reichlich erlebt habe.
Und hier soll es doch erst mal um die Möglichkeiten mit findgehen.

Dass im gleichen Zug wieder die Startparameter als Suchmuster eingesetzt werden, und dann auch noch mit 01 beginnen sollen, ist m.E. over the top. Typischerweise sucht man mit find nun mal rekursiv und würde eine Schleife für so was nutzen - Dein Vorgehen ist zwar für Dich schlüssig, aber nicht für die Allgemeinheit zu empfehlen.

... aber zu Hauf in der Allgemeinheit von Beispielen im Netz zu finden. Scheint also beliebt zu sein (aus wohl unerfindlichen Gründen 😉 )
Es zeigt einfach nur eine fortgeschrittene Variante zum zuerst gezeigten Shell-Glob *.flac.
Hintergrund: In jedem Album-Ordner befinden sich zahlreiche MP3-Dateien. Für den Überblick reicht es, nur die erste davon mit mediainfo zu untersuchen, weil im jeweiligen Album immer dieselben Komprimierungs-Methoden verwendet werden. grep "^Bit rate" findet praktischerweise sowohl die "Bit rate"- als auch die "Bit rate mode"-Werte.

Man kann Shellbefehle ohne Startpunkt=-type f (ordinäre Datei) benutzen und Startpunkte filtern ohne -exec-Varianten filtern.

Verstehe nicht, was Du meinst.

• Abwandlung der durch find gefundenen Strings

Mit Strings meinst Du Dateinamen?

Klaro!

Um zu verstehen, was das 3. Beispiel macht,

Es zeigt im wesentlichen, wie man Dateiendungen der Funde im selben Verzeichnis wandeln und weiterverwenden kann und bedingt verkettet, egal welches Programm das dann nutzen soll, bei mir war's halt ad hoc ffmpeg.

muss ich wieder mitbekommen und erraten, wieso Du nicht nach -name "*.flac" suchst, das .flac-Format kennen, ffmpeg ...

Wie gesagt, hier landet nur der fortgeschrittene User, dem kann man das im Zweifel zumuten. Ich hab's jetzt mit lame vereinfacht, und "transkodiert" sollte auch hinreichend nahelegen, was ".flac" bezeichnen könnte.

mit dieser lustigen Syntax kennen (-c:v -wtf!)

Das hatte ich sogar erklärt: "inklusive evtl. enthaltener Thumbnails" (bei lame nicht mehr nötig).

– der Artikel soll Hürden abbauen, nicht aufbauen! ☺

👍

Ja, das könntest Du als Quiz aufbereiten und dann in "Shell & Programmieren" als kleine Serie aufziehen. ☺

👍

Jetzt muss ich aber zum Grillen!

Hoffentlich überlebst Du das. 😉 Wir brauchen Dich noch.

user_unknown schrieb:

Ich weiß nicht, wieso man ./ vermeiden will/sollte.

Wo wir schon mal dabei sind ... warum funktioniert folgendes eigentlich nicht:

$ find *.flac -print -exec x="{}" \; -exec echo "$x" \;
01 Waits, Tom - Underground.flac
find: ‘x=01 Waits, Tom - Underground.flac’: Datei oder Verzeichnis nicht gefunden
02 Waits, Tom - Shore Leave.flac
find: ‘x=02 Waits, Tom - Shore Leave.flac’: Datei oder Verzeichnis nicht gefunden
[.....]

Gibt's da eine technische Erklärung zu, was da passiert? Ich komme beim besten Willen nicht drauf.

Da die Syntax von "find" doch recht komplex und umfangreich ist, wäre ganz schön, falls es so etwas gibt, auch eine GUI für "find" zu nennen, da nicht unbedingt jeder mit den Befehlszeilen Kommandos arbeiten will oder kann.

Nur mal so als Denkanstoß.

Yabba-Dabba-Doo schrieb:

[...] wäre ganz schön, falls es so etwas gibt, auch eine GUI für "find" zu nennen, [...]

Ist schon im Wiki:

• KFind

Danke für den Hinweis, war mir nicht bekannt

UlfZibis schrieb:

[…] warum funktioniert folgendes eigentlich nicht: […]

Was funktioniert denn nach Deiner Meinung da nicht?

Gibt's da eine technische Erklärung zu, was da passiert?

Du konstruierst – warum auch immer – einen obskuren Dateinamen, zu dem keine Datei existiert, geschweige denn, dass sie ausführbar wäre und willst find zwingen, diese nicht vorhandene Datei zu starten. Da wohl niemand weiß, wie man eine eine nicht vorhandene Datei starten könnte, konnte der Programmierer von find dem Programm das auch nicht beibringen. Statt dessen gibt es eine aussagekräftige Fehlermeldung und somit funktioniert alles so, wie verständige Leute es erwarten.

Ich verstehe allerdings nicht, was Du mit dieser Übung bezweckst?

Gibt's da eine technische Erklärung zu, was da passiert? Ich komme beim besten Willen nicht drauf.

Wie kB schon schrieb, startet "find" mit dem "-exec" ein ausführbares Programm. Es scheint, dass du aber Befehle in einer Shell abarbeiten willst. Wenn diese Vermutung richtig ist, dann musst du mit "-exec" das ausführbare Programm einer Shell (z.B. sh) starten und deine gewünschten Befehle der Shell übergeben.

Ich vermute daher, du meinst folgendes:

$ touch "01 Waits, Tom - Underground.flac"
$ find *.flac -exec sh -c 'x="{}";echo "$x"' \;
01 Waits, Tom - Underground.flac
$ 

kB schrieb:

Was funktioniert denn nach Deiner Meinung da nicht?

Ich denke, alle anderen hier haben das verstanden.
Merkwürdig, nur der Profi mit 9700 Beiträgen nicht.

Du konstruierst – warum auch immer – einen obskuren Dateinamen, zu dem keine Datei existiert, geschweige denn, dass sie ausführbar wäre und willst find zwingen, diese nicht vorhandene Datei zu starten. Da wohl niemand weiß, wie man eine eine nicht vorhandene Datei starten könnte, konnte der Programmierer von find dem Programm das auch nicht beibringen. Statt dessen gibt es eine aussagekräftige Fehlermeldung und somit funktioniert alles so, wie verständige Leute es erwarten.

Deine Antwort wirft mehr Fragen auf, als sie welche beantwortet.

Meine 2 anderen Fragen waren wohl auch zu schwierig für Dich.

Kann es sein, dass hier was ganz anderes im Spiel ist, was Deine Überheblichkeit so triggert?