kB schrieb:
Zu 1: Das ist das bereits oben besprochene Beispiel.
Ich finde im Artikel kein Beispiel, wo die Verkettung von -exec gezeigt wird.
Zu 2: Das ist ähnlich zu bewerten wie 1. Die Aufgabe kann z.B. ohne find viel klarer gelöst werden, sogar als Einzeiler:
for x in */01*.mp3 ; do echo $x ; mediainfo "$x" | grep "^Bit rate" ; done
Das soll besser/unaufwendiger/klarer/kürzer sein als:
find */01*.mp3 -print -exec sh -c 'mediainfo "{}" | grep "^Bit rate"' \; Ich hab' wohl was an den Augen.
Die Syntax von for-Schleifen ist also geläufig und klar ❓ Hinweis: Es gibt mindestens 4 verschiedene Grundvarianten davon. Der Vorschlag zwingt dazu, den nicht gerade kurzen Artikel über das Skripten erst mal studieren zu müssen.
Wenn man dann das Beispiel noch etwas abwandeln will, z.B. rekursiv Suchen oder ein weiteres Such-/Filterkriterium hinzufügen, ist man mit einer for-Schleife bestimmt erst recht besser bedient, als mit find. 😉
So betrachtet ist find ein völlig überflüssiges Programm, denn alles was find kann, lässt sich mit einer for-Schleife erledigen.
Somit ist find kein Missbrauch, sondern die in ein Programm gegossene Umsetzung einer for-Schleife. find macht genau das: In einer (for-)Schleife den Verzeichnisbaum abgrasen ... und für jeden Verzeichniseintrag do ...; ...; done; abarbeiten.
Zu 3: Auch das ist ähnlich, ich spare mir aber ausführliche Ausführungen.
... weil sie auf einem Standardsystem ohne Installation zusätzlicher Pakete gar nicht funktionieren.
Nicht Meckern, sondern ein besseres Beispiel zeigen.
Außerdem muss dann auch ein anderes Beispiel entfernt werden.
Der „Trick“ besteht in allen 3 Beispielen einfach im Missbrauch von find, um sich eine For-Schleife zu sparen und dann mit komplizierten Konstrukten die Probleme zu vermeiden, die man mit klarer Shell Syntax gar nicht hat.
Was ist denn an dem Konstrukt
find *.mp3 -print -exec sh -c '[....."{}".....]' \; komplizierter als an
for x in *.mp3 ; do echo $x ; [....."$x".....] ; done
❓
Auch wie man das vorangestellte "./" in den Suchergebnissen vermeidet, […]
Aus diesem Grund habe ich es jetzt ja auch im Artikel thematisiert,
Daraus geht eben nicht hervor, dass
find *.mp3
die Abkürzung ist von
find . -maxdepth 1 -name "*.mp3" | while read x; do echo ${x/#.\//} ; done ... und dabei hab' ich noch das von Dir angeführte zusätzliche aber überflüssige -print weggelassen.
und es wird eine elegante Lösung mit den Sprachmitteln von find vorgestellt.
... die zudem, wie früher schon "gefeedbacked", falsch ist.
Es ist zwar etwas spät im Jahr, aber ich wünsche trotzdem viel Spaß beim Suchen des Ostereis!
Dito!
Diese Überlegungen sollten noch berücksichtigt werden.
Ich denke, diese Überlegungen habe ich berücksichtigt
Die für mich wichtigste Überlegung darin war, den Leser nicht schon zu Anfang des Artikels mit zu viel Stoff, vor allem mit den so gut wie nie gebrauchten Optionen, zu ermüden. Zumindest ich orientiere mich bei einem Artikel immer zuerst an Beispielen, die hier erst nach ein paar Metern erstmalig auftauchen.
bis auf den Wunsch nach „mit komplizierteren Beispielen die Mächtigkeit von find vor Augen führen“. Darüber habe ich länger nachgedacht und schließlich darauf verzichtet, da ja in der zitierten Dokumentation bereits solche Beispiel erläutert werden und – wie Du ja auch kritisierst – der Artikel bereits ziemlich lang ist.
Es lässt sich auch alles komplett ohne Beispiele erklären. Sie sind völlig überflüssig ... und meistens ja auch länger, als erklärender Text. 🤓
Wo genau steht das in der zur Diskussion stehenden Fassung?
OK, hattest Du schon korrigiert.
Ziemlich nerdig.
Ziemlich nervig, diese Seitenhiebe, Herr Prof. Dr. Deutungshoheit.
Ziemlich nerdig und ziemlich geschraubt gedacht und formuliert. Werde ich nicht berücksichtigen, da meine gewählte Überschrift genau das beschreibt, was hier Sache ist.
Wenn ich "Dateien bearbeiten" lese - vor allem im Inhaltsverzeichnis, denke ich: Den Abschnitt kann ich mir schon mal ersparen, denn Dateien bearbeiten weiß ich ja schon, wie das mit einem normalen Editor geht.
Weitere Details kann man dem Manual (Manpage) ...
Wie wär's statt dessen mit: Manual 🇬🇧, ... und wenn's unbedingt sein muss noch: (Manpage) ?
(Warum gibt obiger Interwiki-Link eigentlich lr=lang_en statt lr=lang_de vor?)
oder man baut find in das Skript ein:
# im Skript:
find … -print |
while read …
do …
done
Das soll also weniger Aufwand sein, sich erst mal in die Syntax von | und gleich 3 Anweisungen (1. while, 2. read, 3. do) einzuarbeiten? ... mal abgesehen von dem Aufwand mit (Dateierstellung, Benennung, Parametrierung, geeigneten Ablageort finden, Überlegungen zur Relativität von verwendeten Pfaden und deren Korrektur, chmod einstellen, etc.).
