UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Was man nicht erklären will ist, wie Find intern arbeitet. Die Methode. Auch das klappt nur bis zu einem gewissen Punkt: Wenn man erklären will, wieso der Test, was -delete löschen würde, ein -depth benötigt, muss man ein wenig über die Methode, wie find arbeitet, erklären, aber auch hier wird man auf einem möglichst abstrakten Niveau bleiben.
Manchmal macht das bis zu einem gewissen Grad Sinn. Nicht umsonst steht in jeder Fahrschule ein Modell, an dem man die interne Funktionsweise einer Kupplung begreifen kann. Es würde theoretisch ja auch die Anweisung reichen, wie sie zu bedienen ist.
Wenn ich eine Datei suche, die weniger als 24 h alt ist, dann interessiert mich das Kriterium, nicht die Methode.
Jain, denn wenn ich die Themen "Startpunkte" -depth etc. verstehen will und spätestens wenn ich das Ergebnis von find nutzen will muss ich ein Verständnis über die Bezeichnungsmethode von Objekten im Dateisystem haben.
Doch in dem strittigen Zusammenhang ging es nicht darum, wie find intern arbeitet, sondern um die Erläuterung der durch den Spruch ausgedrückten Verallgemeinerbarkeit, und die begründet sich auf der identischen Bezeichnungsmethode im Dateisystem.
Nach welcher Methode das Betriebssystem Dateien verzeichnet interessiert für den Artikel nur ganz am Rande - soweit man mit diesem Wissen Find besser verstehen kann. Eine der Informationen ist, dass auch Verzeichnisse und Sockets für Find Dateien sind.
Genau!
Kriterien, die für andere Dateien zur Suche benutzt werden können, wie Suche nach Name, kann man auch auf Verzeichnisse anwenden. Die Methode, wie find das macht, ist die interne Sache von Find und interessiert nicht.
Richtig, aber die Methode, von der Du hier schreibst (wie find die Kriterien intern auswertet), meine ich ja nicht, siehe oben.
Daraus folgt, dass find Dateien sucht, nicht Dateinamen. Dass find Dateinamen per default ausgibt ist nur der Regelfall.
| find -printf "%i %d %s\n"
64682 1 216958
64683 1 211283
64684 1 273346
|
Wieso sollten Dateinamen hier eine Rolle spielen?
Das stimmt, aber auch für diese Ausgabe werden nur die "Einträge" im Verzeichnis(zweig) ge- und durchsucht und ausgewertet. "Dateinamen" war als gefälliges Entgegenkommen für den üblichen Fall zu verstehen.
Auch glaube ich nicht, dass die Dateien hier aufgesucht werden und find diese noch mal abschreitet, um deren Größe zu ermitteln, sondern ich vermute, dass die Größe auch verzeichnet ist.
Genau, und deshalb muss find die Dateien eben nicht suchen, sondern nur deren Einträge im Dateiverzeichnis.
Man könnte höchstens sagen, dass insofern, als die Einträge im Verzeichnis mit den Dateien, die sie bezeichnen, identifiziert werden, die Dateien aufgesucht werden.
Genau, und dass passiert erst, wenn find mit seiner Aufgabe schon fertig ist, und nur wenn dann mit Hilfe der gefundenen Ergebnisse ein Auslesen oder Bearbeiten der identifizierten Dateien erfolgt. Deswegen bin ich gegen diese künstliche Pseudoakkuratesse von Dateinamen und Einträgen und aufsuchen zu reden, solange man damit nicht wirklich etwas erklärt, was sonst missverständlich wäre.
Ist denn die jetzige Form ein Entgegenkommen in Deinem Sinne?
Positionssensitiv
Ich finde die alte Version verständlicher.
Die alte Überschrift suggeriert mir, dass hier positionssensitive Ausdrucksoptionen wie z.B. -follow, -daystart etc. erklärt werden, doch das ist nicht der Fall.
Dieser kann globale und positionale Optionen (nicht zu verwechseln mit den eigentlichen hier nicht beschriebenen Befehlsoptionen),
Wenn, dann "eigentlichen, hier nicht ..." aber wieso eigentlichen? Bist Du Heideggerianer? Das Wort "eigentlichen" einfach Löschen.
Ich wollte damit zum Ausdruck bringen, dass es um die Optionen geht, die dem Befehl find zu eigen sind zur Unterscheidung der Optionen, die dem Ausdruck zu eigen sind. Wenn es Dich zu sehr stört, kann das von mir aus auch weg.
Das war's zu neueren Änderungen. Jetzt noch mal den Vergleich mit 25. Jan. angesehen und folgendes anzumerken (von oben):
Dabei kann es die Suche auf vielfältige Weise filtern, z.B. nach Dateiname, -alter, -größe und die Suchergebnisse auch weiterverarbeiten und/oder formatiert ausgeben.
Das "kann" sagt bereits, dass es optional ist, daher muss das "auch" raus.
Das stimmt schon. Ich wollte zum Ausdruck bringen, dass zusätzlich zur ersten "kann"-Option auch noch zwei weitere davon unabhängige Optionen bestehen. Das "und" kann sonst nach einer Option mit mehreren Aspekten klingen.
Folgende Etiketten können zusätzlich verwendet werden:
Wieso Etiketten statt Marker? In dem Zusammenhang habe ich noch nie Etiketten gehört oder gelesen.
Habe ich nun in "Multiplikatoren" umbenannt. Damit wird nebenbei deutlich, dass auch die größer/kleiner-Abgrenzungslogik – z.B. -5M – diesen Faktoren unterliegt.
Die geläufigsten Aktionen für find
Geläufige Aktionen für find.
"Geläufig" empfinde ich als etwas zu starke Festlegung, da das bedeuten würde, dass alle nicht genannten Aktionen definitiv ungeläufig sind. "Die geläufigsten" ist eine Untermenge von "geläufig" und lässt da mehr Interpretationsspielraum
Das Zeichen ; terminiert den von find aufzurufenden Shellbefehl; damit es nicht unbeabsichtigt von der Shell interpretiert wird, muss es mit \ maskiert werden.
Semikolon ist gut. Vielleicht sogar ". Neuer Satz"?
Noch besser. Auch wenn Du es mir wahrscheinlich kaum glaubst, neige ich zunächst zu minimal-invasiven Änderungen 😉 Vorher stand da ein Komma, was falsch war.
Ergänzend: Damit es nicht unbeabsichtigt von der Shell interpretiert wird, muss es mit \ oder zwei " maskiert werden.
Ich zielte hier mehr auf die Beschreibung des vorliegenden Beispiels als auf eine allgemeine Erklärung. Wäre Dir dennoch der Zusatz passender?
Das ist nämlich bequemer im 10-Finger-System zu tippen.
Gewohnheit. Der \ erspart einen weiteren Tastenanschlag.
Das + bewirkt, dass alle Funde (bzw. hier alle eines gleichen Verzeichnisses) auf einmal an KOMMANDO übergeben werden, was die Ausführung gegebenenfalls stark beschleunigt.
Ist das so? Ich frage, weil die Manpage überraschend defensiv formuliert: This variant of the -exec action runs the specified command on the selected files, but the command line is built by appending each selected
file name at the end; the total number of invocations of the command will be much less than the number of matched files.
Wieso schreibt die Manpage "much less" und nicht "just once"? Kann es sein, dass find die maximale Argumentlänge berücksichtigt? Ich prüfe das jetzt nicht spontan nach, weil es eine sehr große Zahl ist - ich glaube über 100'000 Dateien sind möglich.
Dies präzise zu beschreiben erfordert mehr Worte, was ich dem Leser der Kürze wegen ersparen wollte. Ich denke, das ist ein internes Implementierungsdetail, was den Nutzer nicht unbedingt interessieren muss.
findet nur Verzeichnisse, aber keine sonstigen "Dateien".
Die Anführungsstriche sind falsch, neben der Absicht, die dahinter steht, und die auch falsch ist.
Ich denke, dass habe ich nun geschickt umformuliert.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Man kann die Suchoptionen aber auch per oder bzw. nicht verknüpfen:
Ich schlage eine Auszeichnung von oder und nicht vor. Keine Unterstreichung. Intuitiv tendiere ich zu kursiv, aber diese Wikikonventionen ... 😉
Kursiv bedeutete Zitat. Hatten wir nicht mal die Substantivierung "... per Oder bzw. Nicht ..."? Fand ich auch nicht so schlecht, sonst bleibt noch die Fettung, was immerhin hervorheben würde, um was es geht.
Ohne weitere Angaben gibt find die Namen der gefundenen Dateien aus:
Ohne weitere Angaben gibt find nur die gefundenen Dateinamen aus:
Aktuell sind es mehr Unterschiede, aber was ist der Vorteil der Satzumstellung? Dass ich jedes Mal drüber nachdenken darf, was Dein Motiv dafür war, wenn ich mir die Unterschiede anschaue? Ob da ein subtiler Unterschied besteht?
Der Mädchenname Mercedes kann auch ein Auto benennen, der Name eines Autos kann nie ein Mädchen sein. Weiterhin findet find ja nur Namen und keine Dateien. "nur" im Gegensatz zu -ls . Warum also nicht "wahr" bleiben im Wiki, wenn es nichts kostet sondern sogar zum kürzeren Satz führt?
find ... + klappt sehr wohl mit md5sum:
Mit "klappt nicht" meinte ich, dass im Ergebnis mit ';' kein Unterschied zu dem mit '+' erkennbar ist.
Das ist ja gerade der Witz an +. Nur wenn es keinen sichtbaren Unterschied in der Ausführung macht kann man ";" umstandslos mit "+" ersetzen. Ansonsten war das Kommando mit ";" falsch.
Mein Verständnis war, dass die unterschiedliche Wirkung von ; und + demonstriert werden soll, nicht wann man es folgenlos austauschen kann, was man natürlich auch geeignet demonstrieren könnte, was aber beim alten Beispiel mit der – zwar nicht zutreffenden – einzeiligen Ausgabe von md5sum auch nicht der Fall war.
find -name "*pdf" -exec du --total {} ";"
--total macht ja hier gar keinen Sinn.
Genau das soll demonstriert werden, und dass man dann auf '+' zurückgreifen kann.
Kombination mit -or (und evtl. -and) ergibt unerwartetes
OR und AND statt UND und ODER, gut. Aber Wieso evtl. vor and und wieso in Klammern? Ererbter Fehler: Unerwartetes groß, oder?
In Klammern, weil ein -and auch implizit vorliegt, wenn es nicht extra hingeschrieben wird.
Positionssensitiv
Das Wort ist signifikant in der Fehlermeldung, deswegen habe ich es als Zwischenüberschrift gewählt.
Siehe letzter Post; wenn schon, dann müsste die Überschrift "Nicht positionssensitiv" lauten.
Allerdings:
| find ./SUCHVERZEICHNIS -maxdepth 4 -name foo -or -maxdepth 2
find: Warnung: Sie haben die Option -maxdepth nach dem Argument -name angegeben, aber Optionen sind nicht positionssensitiv (-maxdepth beeinträchtigt sowohl Tests, die vor ihr als auch nach ihr definiert sind). Bitte geben Sie Optionen vor anderen Argumenten an.
find --version
find (GNU findutils) 4.4.2
Copyright (C) 2007 Free Software Foundation, Inc
|
Ich nehme an die neue Meldung ist von einem aktuelleren Find.
Ja: $ find --version
find (GNU findutils) 4.7.0-git
Copyright (C) 2016 Free Software Foundation, Inc.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: und wenn, dann würde ich ein Beispiel wählen, das auch einen relativen Pfad zeigt.
Da muss ich Dir recht geben, allerdings fand ich das Beispiel aus dem prominenten grub-Verzeichnis so nett, dass ich es nicht über mich brachte, es zu ersetzen. Wir können das "relativ" allerdings auch einfach weg lassen, was auch der Würze der Kürze dient.
Es wurde sonst aber noch nie gesagt, und langsam wird es mal Zeit und hier wäre ein geeigneter Ort. Da man beim Öffnen des Terminals per Default in ~ landet wäre ~/.config ein Verzeichnis, das sich anbietet.
Das ist auch ein Aspekt. Darf ich Dir die Änderung überlassen? Startpunkt(e)
Dort beginnt find mit der Suche – im aktuellen Verzeichnis, wenn keine extra angegeben sind.
Wieso extra? Wenn keine angegeben sind.
So ein Füllsel aus der Umgangssprache, "explizit" klingt so gestelzt, kann von mir aus auch weg.
Explizit bedeutet ausdrücklich, extra bedeutet zusätzlich.
Ich kann damit leben, dass darunter ein Zusatz verstanden wird.
Vorschlag: Wenn keine Startpunkte angegeben sind beginnt find mit der Suche im aktuellen Verzeichnis.
Hm, ich finde die quasi alleinstehende Erklärung, wozu ein Startpunkt überhaupt dient, schon sinnvoll.
Dort beginnt find mit der Suche – im aktuellen Verzeichnis, wenn keine extra angegeben sind.
Beinhalten die gleichen Informationen, nur dass das "wenn keine extra angegeben sind" mich stolpern läßt - keine extra was? Ah - die Startpunkte aus der Überschrift! Mein Satz liest sich m.E. dagegen geschmeidig. Klingt, wie von einem Muttersprachler geschrieben.
Klar ist das geschmeidiger, doch mir gefällt es, dass durch den Gedankenstrich der Hauptaspekt vom Nebenaspekt deutlich abgetrennt ist.
Wie gesagt, das war kein Unfall, dass ich ein Verzeichnis test gewählt habe.
A zeigt es einen Startpunkt. B bringt es subtil die Idee ins Spiel, heikle Kommandos zu testen C verwendet es dafür den ausdrucksstarken Namen test, dem man 3 Monate später begegnen darf und denken, ach das könnte ich noch löschen. D eröffnet es für die Beschreibung eine Alternative zu dem sonst oft benutzten "aktuellen Verzeichnis und seinen Unterverzeichnissen" E wenn jemand falsch "find -test/...." oder "find -test ..." überträgt bekommt er eine klare und einfache Fehlermeldung, weil es keinen Schalter -test gibt.
Interessante zusätzliche Aspekte. Ich denke, STARTVERZEICHNIS erfüllt zumindest A, D und E.
Meine Bedenken zu B und C hatte ich schon mal vor ein paar Tagen geäußert. Ich finde es bedenklich aus dem gewünschten Ergebnis in einem Testordner vorschnell auf das richtige Funktionieren in beliebigen realen Ordnern – z.B. per Script – zu schließen. Außerdem finde ich es verwirrend, in einem Beispiel gleich 2 Testmethoden zusammenzustricken. Es könnte auch so verstanden werden, dass man dann vielleicht auf das Testen mit -depth und ohne -delete verzichten könnte.
Gibt es nicht. Bzw. das wäre ein so grober Fehler, dass es wünschenswert ist, dass dieser früh passiert. Fail early!
Dann ist es aber schon zu spät, wenn reale Daten so vernichtet wurden.
Merkwürdigerweise ist Dir trotz der falschen Gründe eine bessere Formulierung gelungen. Ausgabe erzwingen mit -print ist eine Punktlandung. Insofern verurteile ich Dich nur zu einem Video belleslettres: "Anführungszeichen" http://www.belleslettres.eu/content/zeichensetzung/anfuhrungszeichen.php das ich auch allen anderen Freunden des Gänsefüßchens empfehle, Gesamtspielzeit 75 min., ab 0:49 geht es um Ironie und Hohn mit Gänsefüßchen.
Sehr Amüsant!
Strukturell ist das begründbar, aber didaktisch halte ich die alte Form für besser. Die Logik des Ganzen ist die: Wenn keine Aktion angegeben wird, dann wird stillschweigend -print ausgeführt.
Das finde ich aber eine ziemlich gewollte Interpretation bzw. Didaktik. Demnach müssten alle GNU-Befehle, welche was ausgeben, eine -print-Aktion haben, die im geeigneten Fall still verschwiegen werden kann. Sonst bräuchte man ja eine Option -suppressprint oder -noprint
Wenn -print eine Aktion ist müsste das aber eine Gegen- oder Antiaktion sein 😀
| unzip2 8832788-archiv.bz2
...
|
Welches Problem sehe ich nicht? Das sieht aus, wie das, was in der anderen Datei drin ist. Habe ich damals doch keinen Unfug gemacht?
Wie schon erwähnt, probier das Entpacken mal mit dem graphischen File Roller.
Ein Textmarker ist ein leuchtender Stift, und ein Etikett ist ein Klebezettel.
Etiketten können auch genäht, gesteckt oder angehangen sein.
| t201:~/proj/mini/forum/test/foo > find B
B
B/C
B/C/a3.txt
B/C/a1.txt
B/Bild1.jpg
t201:~/proj/mini/forum/test/foo > find -mindepth 2 -maxdepth 2
./B/C
./B/Bild1.jpg
|
Tiefe 0 ist der Punkt. Tiefe 1 ist B.
In Tiefe 0 sucht find aber nichts; mit -mindepth 0 fängt find erst ab der Tiefe 1 mit dem Suchen an. Im Parkhaus finde ich jedoch in Tiefe 0 schon viele Autos, wenn ich danach suche. Die Logik von find entspricht also nicht dem gewöhnlichen Sprachgebrauch, wo man schon in Tiefe 0 suchen und was finden kann. Auf diesen Umstand sollte man IMHO deutlich und unmissverständlich hinweisen.
Ist: -maxdepth n sucht ab dem Startpunkt nur n Verzeichnisse tief. Bezeichnet dieser ein Verzeichnis – z.B. . – zählt dessen Inhalt schon zur Tiefe 1.
Soll: -maxdepth n sucht ab dem Startpunkt (Tiefe 0) maximal n Verzeichnisse tief.
Zugegeben elegant. Die erste Form weist m.E. aber deutlicher auf die Diskrepanz zum normalen Sprachgebrauch hin.
Der Startpunkt kann selbst immer gefunden werden und dieser soll wohl nicht -1 als negativen Index bekommen. Also ist der Startpunkt 0. Er könnte allenfalls selbst 1 sein und dann wäre alles tiefere noch eins tiefer.
Dass der Startpunkt selbst gefunden wird ist halt dem überraschenden Umstand zu schulden, dass find , wenn es Deiner Schreibe gemäß in einem Verzeichnis sucht, nicht nur das findet, was sich im Verzeichnis befindet.
Wenn ich im Erdgeschoss eines Parkhauses beginne Autos zu suchen, finde ich schon welche in Tiefe 0, nicht erst in Tiefe 1 wie bei find .
Der Vergleich passt nicht, weil eine Ebene immer nur Autos enthält und nicht weitere Ebenen. Und weil Du immer nur Autos suchst, nicht Ebenen.
Den Aspekt hatte ich hier weggelassen. Den Vergleich mit der vollständigen Situation hatte ich schon mal in 8780638 anhand einer Tiefgarage – wo Tiefe besser passt, als im Parkhaus – mit ebenerdiger Startebene (Parkplatz) dargestellt. Wenn Du Ebenen finden willst, brauchst Du eine Ebene 0 und was darin ist - in dem Falle Autos, wäre Ebene 1, aber Ebene 1 ist nicht in Ebene 0, sondern darüber.
Im Parkhaus, in dem ich rote Autos suche, gibt es in Ebene 0 also keine zu finden?
Wenn ich in einem Buch suche, finde ich da Text und evtl. Kapitel (=Unterverzeichnisse), beides in Tiefe 0. Der Eintrag des Buchs im Katalog der Bibliothek ist dann eine Ebene höher, also Tiefe -1.
Passt auch nicht aus den gleichen Gründen. Kapitel 2 ist nicht in Kapitel 1 sondern nach Kapitel 1.
Hab' ich auch nicht so gemeint. In den Kapiteln befinden sich dann einzelne Sätze als auch Absätze, die dann der Tiefe 1 angehören, und in den Absätzen wiederum Sätze, diesmal in der Tiefe 2. Es gibt keine leeren Kapitel, usw.
Als künstlerischer Effekt ist auch ein unbeschriebenes, also leeres Kapitel denkbar.
sucht nach den vollständigen Namen hausarbeit.odt.
Hm. hier sucht find also ausnahmsweise mal nach Namen, und nicht nach Dateien.
find -name hausarbeit.odt Hier wird mit dem Namen gesucht. Ist das wirklich erklärungsbedürftig?
Also was denn nun, mit oder nach Namen?
😀 Da sonst im ganzen Artikel nach Dateien gesucht wird klingt diese Unterscheidung für mich hier dann nach "sucht nach Namen in Dateien", also das, was eigentlich nur grep kann.
Hausarbeit klein und .odt und Du meinst dann, es sucht nach Wörtern in der Datei? Nein, nicht nach Wörtern, nach Namen!
In dem Zusammenhang, dass wir festgelegt haben, dass find eine Instanz zur Dateisuche und nicht zur Namenssuche ist, klingt obiger Satz halt wie "Der Tierfotograf sucht nach vollständigen Organen Affe" ... statt nach Tieren die Affen sind.
Hm, weil es eben auch keine Sockets etc. findet. Korrekt wäre: findet nur Verzeichnisnamen, aber keine sonstigen.
Das ist nur Dein Eindruck, dass Dateinamen, hier Verzeichnisnamen gesucht werden. Es werden nur Namen ausgegeben, wenn man nichts anderes spezifiziert - gesucht wird immer das gleiche.
... nämlich Einträge, die unter anderem Namen enthalten.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Bei mir kommt es so rüber: Du fragst nicht vor dem Ändern, wieso es nicht so gemacht wird, wie es Deinem Sprachgefühl entspricht, sondern änderst erst mal.
Tut mir leid, wenn das so wirkt. Habe ich aber nur ausnahmsweise so gemacht, sonst frage ich doch immer erst langwierig hier im Forum nach, solange ich es nicht für eine Bagatelle halte. Und Du begründest Deine Änderung erst, nachdem sich jemand beschwert.
Immerhin schreibe ich ein wenig mehr als das berühmte 'm'. So komme ich immer in die aggressive Rolle, aber von mir aus.
Wäre das nicht eher die defensive (verteidigende) Rolle?
man find:
| %d File's depth in the directory tree; 0 means the file is a command line argument.
|
Sehr schön, im 2. Halbsatz steht doch quasi das gleiche, was ich im letzten Post mit dem Zusatz "zählt dessen Inhalt schon zur Tiefe 1" ausdrücken wollte. Im Kontext der Suche einer Datei im Dateisystem hat eine Datei sehr wohl eine Tiefe.
Nein doch, sie hat keine Tiefe, sondern befindet sich in Tiefe x im Verzeichnisbaum (depth in the directory tree).
sucht von Verzeichnistiefe 3 bis 5.
ist ja aus dem Kontext der davor zahlreich aufgeführten Formulierungen die Kurzform von sucht Dateien von Verzeichnistiefe 3 bis 5.
Nein. Sucht von Verzeichnistiefe 3 bis 5 nach Dateien.
Ok, dann fügen wir der Vollständigkeit halber noch "nach" ein und stellen den Satz in grammatikalisch richtiger Weise um: sucht nach Dateien von Verzeichnistiefe 3 bis 5.
Im November oder Januar habe ich schon mal geschrieben, dass "ab" im Kontext von Ästen und Knoten eine gute Wahl sein kann.
Also für einen Startpunkt ist "ab" ok, wenn der ein Verzeichnis ist und als solches benannt wird, nicht mehr? Wenn der User aber ein Verzeichnislisting gewohnt ist wie:
| bin
boot
dev
etc
home
lib
mnt
opt
...
|
"ab etc" als "etc, home, lib, ..." gedeutet werden kann.
Klar kann man das so missverstehen, halte ich aber für unrealistisch, und erst recht, wenn wir im "unbenamten" aktuellen Verzeichnis . starten. Außerdem wissen wir, dass find zunächst mal in die Tiefe geht, und eben nicht in die Startebene.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Das ist falsch. löscht auch Verzeichnisse, die nicht leer sind.
Dann habe ich wohl falsch verstanden, was unter rm --help zu lesen steht: -d, --dir leere Verzeichnisse werden entfernt
Warum wird da "leere" betont, wenn auch volle gelöscht werden?
Vorschlag: find test/ -name "c*" -delete
Löscht im Verzeichnis test und dessen Unterverzeichnissen alle Dateien, die mit 'c' beginnen. Der Befehl löscht auch Verzeichnisse selbst, die mit 'c' beginnen, sofern sie leer sind, wie bei rmdir. Das ist der Grund, weshalb -delete ein -depth impliziert: Wenn erst in den Verzeichnissen gelöscht wird kann ein dadurch leeres auch selbst gelöscht werden, umgekehrt nicht.
Es ist sinnvoll in dem Abschnitt etwas redundanter vorzugehen als sonst im Artikel, weil man zum Löschen Leute auch mal im Support auf find/-delete hinweist, die dann nicht den ganzen Artikel von oben bis unten lesen.
Darauf wird aber hoffentlich nur verwiesen, wenn tatsächlich die rekursive Bearbeitung erwünscht ist. Deswegen wurde hier noch mal extra "Unterverzeichnisse" betont
Hm, meinst Du wirklich? Der Preis ist, dass dann andere wichtige Aspekte, wie das mit den leeren Verzeichnissen, in der Position nach hinten rücken.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
noisefloor schrieb: Hallo, fertig?
Von meiner Seite habe ich jetzt wieder die Stufe "fertig" erreicht. Wer was anders haben möchte, möge es bitte selbst tun.
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29065
Wohnort: WW
|
Hallo,
Von meiner Seite habe ich jetzt wieder die Stufe "fertig" erreicht.
Gut. Dann warten wir noch die üblichen paar Tage, ob noch anderen Nutzer Anmerkungen / Fragen / ... haben und verschieben dann spätestens nach Ostern. Gruß, noisefloor
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29065
Wohnort: WW
|
Hallo, was länger währt wird endlich gut: der Artikel ist wieder im Wiki ☺ Gruß, noisefloor
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Tja, ich hatte eine Zeitlang keine Zeit. Leider ist soviel Zeit verstrichen, und da die Zitate oft des Kontextes entbehren, aus dem sie stammen, ist es mühsam die Diskussion zu rekonstruieren. Allerdings hilft das auch, das unwichtig empfundene vom Wichtigen zu trennen und manchen Punkt unter den Tisch fallen zu lassen. UlfZibis schrieb: user_unknown schrieb: Was man nicht erklären will ist, wie Find intern arbeitet. (...)
Manchmal macht das bis zu einem gewissen Grad Sinn. Nicht umsonst steht in jeder Fahrschule ein Modell, (...)
Jain, denn wenn ich die Themen "Startpunkte" -depth etc. verstehen will und spätestens wenn ich das Ergebnis von find nutzen will muss ich ein Verständnis über die Bezeichnungsmethode von Objekten im Dateisystem haben.
Also ich behaupte, dass die Schematik von find bei der Verwendung von -depth keinen Sinn hat, der sich mit einfachen Mitteln erschließt. Wenn die Diskussion aufkommt muss ich nach einer Woche wieder ausprobieren, wie es geht, was es macht, in den Randfällen. Es ist logisch, dass Verzeichnisse mit -mindepth 4 eine Etage tiefer liegen als mit -mindepth 3, aber was -mindepth 0 ist, ist nicht logisch.
Mein Versuch es damit zu erklären, dass in jedem Verzeichnis ein Link . ist, ist auch nicht konsistent. Es ist eine find-eigene Konvention für den Spezialfall das Startverzeichnis aus der Trefferliste auszuschließen. Wer sich das merken kann - gut! Wer nicht muss eben testen/prüfen oder nachschlagen. Bei dem Vorfall, bei dem Du Dir die Finger verbrannt hast, hattest Du da -mindepth benutzt? War das eine Deiner ersten find-Erfahrungen? Oder wieso ist Dir nicht früher aufgefallen, das find das aktuelle Verzeichnis oder explizite Startverzeichnis mitliefert?
Daraus folgt, dass find Dateien sucht, nicht Dateinamen. Dass find Dateinamen per default ausgibt ist nur der Regelfall.
| find -printf "%i %d %s\n"
64682 1 216958
64683 1 211283
64684 1 273346
|
Wieso sollten Dateinamen hier eine Rolle spielen?
Das stimmt, aber auch für diese Ausgabe werden nur die "Einträge" im Verzeichnis(zweig) ge- und durchsucht und ausgewertet. "Dateinamen" war als gefälliges Entgegenkommen für den üblichen Fall zu verstehen.
Wie großzügig! Wenn Deine Freundin aus der Wohnstube ruft "Spiel doch noch mal den Song von gestern!" - wie würdest Du antworten? "Moment, ich weiß nicht mehr, wo ich den gespeichert habe, ich muss ihn erst suchen!" " ... ich muss erst die Datei suchen!" " ... ich muss erst den Dateinamen suchen!" " ... ich muss erst den Eintrag des Dateinamens suchen!"
Ich tippe ja auf 1, maximal 2. Womöglich kennst Du den Namen ja ("Abraxas.mp3") und suchst mit dem Namen nach ... der Datei. Du suchst nicht den Namen; den kennst Du schon. Insofern, als der Name den Pfad zur Datei beinhaltet ist er ein eindeutiger Identifier für die Datei. Der Song, die Datei, der Dateiname, der Dateiverzeichniseintrag - das kann alles oft synonym verwendet werden, und wenn man nicht aus besonderen Gründen sperrig klingen will, wählt man die griffigste Formulierung. Da der Artikel nicht nur von Mp3s handelt schreiben wir nicht, wie man Songs sucht, sondern Dateien.
Genau, und deshalb muss find die Dateien eben nicht suchen, sondern nur deren Einträge im Dateiverzeichnis.
Die Einträge im Dateiverzeichnis interessieren nur mittelbar, als sie den Zugriff auf die Datei erlauben. Es kann auch sein, dass nur der Name interessiert - das ist aber ein Sonderfall. Im Normalfall gibt find den Namen aus und druckt die Datei nicht etwa oder spuckt sie aus dem Diskettenlaufwerk aus. Textdateien könnte find auch auf dem Bildschirm ausgeben, selbst Bilder und Videos, aber das wird kaum ein User erwarten. Spätestens nach den ersten zwei, drei Experimenten mit find oder gelesenen Beispielen ist klar: die Namen werden ausgegeben. Und später, dass dem nicht so sein muss.
Man könnte höchstens sagen, dass insofern, als die Einträge im Verzeichnis mit den Dateien, die sie bezeichnen, identifiziert werden, die Dateien aufgesucht werden.
Genau, und dass passiert erst, wenn find mit seiner Aufgabe schon fertig ist, und nur wenn dann mit Hilfe der gefundenen Ergebnisse ein Auslesen oder Bearbeiten der identifizierten Dateien erfolgt.
Nein. Wenn find fertig wäre hätte es die Kontrolle abgegeben und könnte nichts mehr mit den Dateien machen, weil es beendet wäre.
Das war's zu neueren Änderungen. Jetzt noch mal den Vergleich mit 25. Jan. angesehen und folgendes anzumerken (von oben):
Dabei kann es die Suche auf vielfältige Weise filtern, z.B. nach Dateiname, -alter, -größe und die Suchergebnisse auch weiterverarbeiten und/oder formatiert ausgeben.
Das "kann" sagt bereits, dass es optional ist, daher muss das "auch" raus.
Das stimmt schon. Ich wollte zum Ausdruck bringen, dass zusätzlich zur ersten "kann"-Option auch noch zwei weitere davon unabhängige Optionen bestehen. Das "und" kann sonst nach einer Option mit mehreren Aspekten klingen.
Verstehe nicht, was Du meinst.
Folgende Etiketten können zusätzlich verwendet werden:
Habe ich nun in "Multiplikatoren" umbenannt.
Auch gut.
Die geläufigsten Aktionen für find
Geläufige Aktionen für find.
"Geläufig" empfinde ich als etwas zu starke Festlegung, da das bedeuten würde, dass alle nicht genannten Aktionen definitiv ungeläufig sind.
Das ist falsch.
Wenn ich sage die Beatles und die Stones sind bekannte Popstars sage ich nicht, dass Prince und Michael Jackson unbekannt sind. Wenn ich aber sagte, dass die Beatles und die Stones die bekanntesten Popstars sind, dann sage ich, dass sie bekannter sind als Prince und Jackson.
"Die geläufigsten" ist eine Untermenge von "geläufig" und lässt da mehr Interpretationsspielraum
Ein Irrtum. Der bekannteste, schwarze Philosoph des 18. Jahrhunderts ist wohl Anton Wilhelm Amo, aber er ist alles andere als bekannt.
Ergänzend: Damit es nicht unbeabsichtigt von der Shell interpretiert wird, muss es mit \ oder zwei " maskiert werden.
Damit es nicht unbeabsichtigt von der Shell interpretiert wird, muss es mit \ oder zwei umschließenden " maskiert werden.
Das + bewirkt, dass alle Funde (bzw. hier alle eines gleichen Verzeichnisses) auf einmal an KOMMANDO übergeben werden, was die Ausführung gegebenenfalls stark beschleunigt.
Ist das so? Ich frage, weil die Manpage überraschend defensiv formuliert: This variant of the -exec action runs the specified command on the selected files, but the command line is built by appending each selected
file name at the end; the total number of invocations of the command will be much less than the number of matched files.
Wieso schreibt die Manpage "much less" und nicht "just once"? Kann es sein, dass find die maximale Argumentlänge berücksichtigt? Ich prüfe das jetzt nicht spontan nach, weil es eine sehr große Zahl ist - ich glaube über 100'000 Dateien sind möglich.
Dies präzise zu beschreiben erfordert mehr Worte, was ich dem Leser der Kürze wegen ersparen wollte. Ich denke, das ist ein internes Implementierungsdetail, was den Nutzer nicht unbedingt interessieren muss.
Das muss ihn auch nicht interessieren, wenn man korrekt
-execdir KOMMANDO {} +
wendet auf die Funde den Shellbefehl KOMMANDO an. Im Gegensatz zu -exec wird das Kommando im Verzeichnis, in dem die Datei liegt, ausgeführt. Das + bewirkt, dass viele Funde (bzw. hier alle eines gleichen Verzeichnisses) auf einmal an KOMMANDO übergeben werden, was die Ausführung stark beschleunigen kann. Das + kann statt dem ; (ebenso wie bei -exec ) nur verwendet werden, wenn {} der letzte Parameter von KOMMANDO ist.
schreibt und erfordert auch nicht mehr Worte. (Änderungen eingepflegt)
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb: Ohne weitere Angaben gibt find die Namen der gefundenen Dateien aus:
Ohne weitere Angaben gibt find nur die gefundenen Dateinamen aus:
Aktuell sind es mehr Unterschiede, aber was ist der Vorteil der Satzumstellung? Dass ich jedes Mal drüber nachdenken darf, was Dein Motiv dafür war, wenn ich mir die Unterschiede anschaue? Ob da ein subtiler Unterschied besteht?
Der Mädchenname Mercedes kann auch ein Auto benennen, der Name eines Autos kann nie ein Mädchen sein. Weiterhin findet find ja nur Namen und keine Dateien. "nur" im Gegensatz zu -ls . Warum also nicht "wahr" bleiben im Wiki, wenn es nichts kostet sondern sogar zum kürzeren Satz führt?
Was hat jetzt der Mädchenname Mercedes damit zu tun? Dass Deine Datei Mercedes heißen kann? Ein Autoname kann nie ein Mädchen sein, aber ein Mädchenname kann ein Auto sein? Du versuchst wieder Sprachtricksereien. Der Autoname Mercedes kann ein Mädchen benennen, so what? Du willst zeigen, dass eine Sache in die eine Richtung stimmt aber nicht in die andere und bei der Richtungsumkehr änderst Du gleich einen Haufen Zeuch mit, weil es sonst nicht hinhaut. Soll ich denken, dass Du das selbst nicht merkst? Eine der beiden Formulierungen
legt nahe, dass man nach Dateinamen gesucht hat. Rate mal welche?
find ... + klappt sehr wohl mit md5sum:
Mit "klappt nicht" meinte ich, dass im Ergebnis mit ';' kein Unterschied zu dem mit '+' erkennbar ist.
Das ist ja gerade der Witz an +. Nur wenn es keinen sichtbaren Unterschied in der Ausführung macht kann man ";" umstandslos mit "+" ersetzen. Ansonsten war das Kommando mit ";" falsch.
Mein Verständnis war, dass die unterschiedliche Wirkung von ; und + demonstriert werden soll, nicht wann man es folgenlos austauschen kann, was man natürlich auch geeignet demonstrieren könnte, was aber beim alten Beispiel mit der – zwar nicht zutreffenden – einzeiligen Ausgabe von md5sum auch nicht der Fall war.
Das war keine Ausgabe von md5sum, sondern es waren die äquivalenten Befehle, die man auf der Shell eingeben kann. Insofern es missverständlich war, war es verbesserungs- bzw. erklärungswürdig. ist vom Ergebnis äquivalent zu | md5sum a
md5sum b
md5sum c
|
aber mal sind es 3, mal ist es ein Programmaufruf. Das eine entspricht find/exec mit Semikolon, das andere dem mit Plus. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | t201:~/proj/mini/forum/xx/b > md5sum a b c
60b725f10c9c85c70d97880dfe8191b3 a
3b5d5c3712955042212316173ccf37be b
2cd6ee2c70b0bde53fbe6cac3c8b8bb1 c
t201:~/proj/mini/forum/xx/b > md5sum a; md5sum b; md5sum c
60b725f10c9c85c70d97880dfe8191b3 a
3b5d5c3712955042212316173ccf37be b
2cd6ee2c70b0bde53fbe6cac3c8b8bb1 c
t201:~/proj/mini/forum/xx/b > find -type f -exec md5sum {} +
2cd6ee2c70b0bde53fbe6cac3c8b8bb1 ./c
3b5d5c3712955042212316173ccf37be ./b
60b725f10c9c85c70d97880dfe8191b3 ./a
t201:~/proj/mini/forum/xx/b > find -type f -exec md5sum {} ";"
2cd6ee2c70b0bde53fbe6cac3c8b8bb1 ./c
3b5d5c3712955042212316173ccf37be ./b
60b725f10c9c85c70d97880dfe8191b3 ./a
|
Wie Sie sehen sehen Sie nichts. Also keinen Unterschied.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33 | t201:~/proj/mini/forum/xx/b > time find -type f -exec md5sum {} ";"
2cd6ee2c70b0bde53fbe6cac3c8b8bb1 ./c
3b5d5c3712955042212316173ccf37be ./b
60b725f10c9c85c70d97880dfe8191b3 ./a
real 0m0.006s
user 0m0.000s
sys 0m0.000s
t201:~/proj/mini/forum/xx/b > time find -type f -exec md5sum {} +
2cd6ee2c70b0bde53fbe6cac3c8b8bb1 ./c
3b5d5c3712955042212316173ccf37be ./b
60b725f10c9c85c70d97880dfe8191b3 ./a
real 0m0.004s
user 0m0.000s
sys 0m0.000s
t201:~/proj/mini/forum/xx/b > time (md5sum a; md5sum b; md5sum c)
60b725f10c9c85c70d97880dfe8191b3 a
3b5d5c3712955042212316173ccf37be b
2cd6ee2c70b0bde53fbe6cac3c8b8bb1 c
real 0m0.006s
user 0m0.000s
sys 0m0.000s
t201:~/proj/mini/forum/xx/b > time (md5sum a b c)
60b725f10c9c85c70d97880dfe8191b3 a
3b5d5c3712955042212316173ccf37be b
2cd6ee2c70b0bde53fbe6cac3c8b8bb1 c
real 0m0.002s
user 0m0.000s
sys 0m0.000s
|
Das Holzhammerbeispiel mit dem --total ist aber didaktisch nicht notwendig schlechter, vielleicht sogar besser.
find -name "*pdf" -exec du --total {} ";"
--total macht ja hier gar keinen Sinn.
Genau das soll demonstriert werden, und dass man dann auf '+' zurückgreifen kann.
Ich fand es interessant darauf hinzuweisen, dass es einen Unterschied machen kann, ohne einen semantischen Unterschied zu machen - Geschwindigkeit, Zahl der gestarteten Prozesse. Relativ wirken die Zahlen von time ja enorm - die Hälfte größere Laufzeit mit Semikolon, aber die Dateien bestehen auch nur aus einem Byte, und je größer die Dateien sind, desto geringer dürfte der Geschwindigkeitsgewinn sein. Es wirkt sich also spürbar nur aus, wenn es sehr viele Dateien sind, die Find weiterreicht und die Bearbeitungszeit für jede einzelne gering ist. Oder wenn das aufgerufene Programm die Arbeit sehr gut parallelisieren kann. Oder wenn das Programm - etwa weil es erst die JVM läd - eine lange Startphase hat.
Kombination mit -or (und evtl. -and) ergibt unerwartetes
OR und AND statt UND und ODER, gut. Aber Wieso evtl. vor and und wieso in Klammern? Ererbter Fehler: Unerwartetes groß, oder?
In Klammern, weil ein -and auch implizit vorliegt, wenn es nicht extra hingeschrieben wird.
Kombinationen nur aus ORs können schlecht etwas unerwartetes produzieren, sind wir uns da einig?
Und Kombinationen nur aus ANDs auch nicht, gehst Du mit?
Nur die Kombination von OR und AND kann unerwartetes ergeben - völlig unabhängig, ob das AND explizit oder implizit ist. Dass die Klammern symbolisieren sollen, dass es immer Kombinationen aus OR und AND sind, die wenn, dann problematisch sein können, und dass die Klammern und/oder das evtl. auf die implizite Natur des AND hinweisen sollen, oder beide gemeinsam ... - wer soll da drauf kommen? Das sind Cover-my-Ass-Sprachverrenkungen. Neu: Kombination von -or und -and ergibt Unerwartetes
Bei der Oder- und Und-Verknüpfung von Optionen helfen Klammern, Fehler zu vermeiden.
Ich nehme an die neue Meldung ist von einem aktuelleren Find.
Ja: $ find --version
find (GNU findutils) 4.7.0-git
Copyright (C) 2016 Free Software Foundation, Inc.
Für 17.04 finde ich 4.6.0 als Version.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb:
Wie gesagt, das war kein Unfall, dass ich ein Verzeichnis test gewählt habe.
A zeigt es einen Startpunkt. B bringt es subtil die Idee ins Spiel, heikle Kommandos zu testen C verwendet es dafür den ausdrucksstarken Namen test, dem man 3 Monate später begegnen darf und denken, ach das könnte ich noch löschen. D eröffnet es für die Beschreibung eine Alternative zu dem sonst oft benutzten "aktuellen Verzeichnis und seinen Unterverzeichnissen" E wenn jemand falsch "find -test/...." oder "find -test ..." überträgt bekommt er eine klare und einfache Fehlermeldung, weil es keinen Schalter -test gibt.
Interessante zusätzliche Aspekte. Ich denke, STARTVERZEICHNIS erfüllt zumindest A, D und E.
Meine Bedenken zu B und C hatte ich schon mal vor ein paar Tagen geäußert.
Finde ich nicht mehr.
Ich finde es bedenklich aus dem gewünschten Ergebnis in einem Testordner vorschnell auf das richtige Funktionieren in beliebigen realen Ordnern – z.B. per Script – zu schließen.
Vorschnelles Schließen wird auch nicht empfohlen, sondern Testen. Inwiefern das Arbeiten ohne Test besser sein soll, als ein möglicherweise unzureichender Test - nur dann hätte Dein Argument Sinn - erschließt sich mir nicht.
Außerdem finde ich es verwirrend, in einem Beispiel gleich 2 Testmethoden zusammenzustricken.
Inwiefern 2 Testmethoden?
Es könnte auch so verstanden werden, dass man dann vielleicht auf das Testen mit -depth und ohne -delete verzichten könnte.
Sehe ich nicht, wieso das so verstanden werden könnte, außer jemand versteht immer nur Bahnhof, dann versteht er hier natürlich Bahnhof.
Gibt es nicht. Bzw. das wäre ein so grober Fehler, dass es wünschenswert ist, dass dieser früh passiert. Fail early!
Dann ist es aber schon zu spät, wenn reale Daten so vernichtet wurden.
Backup.
Die Logik des Ganzen ist die: Wenn keine Aktion angegeben wird, dann wird stillschweigend -print ausgeführt.
Das finde ich aber eine ziemlich gewollte Interpretation bzw. Didaktik. Demnach müssten alle GNU-Befehle, welche was ausgeben, eine -print-Aktion haben, die im geeigneten Fall still verschwiegen werden kann.
In der Tat gibt es eine Vielzahl ärgerlicher Programme, die mit ihrer geschwätzigen Art
| wc -l d.html/f.html/test.txt
1 d.html/f.html/test.txt
|
dafür sorgen, dass man, wenn man das Ergebnis braucht, die Dekoration erst wegschneiden muss. Wenn sie wenigstens einen Schalter --no-headline oder --core hätten.
| unzip2 8832788-archiv.bz2
...
|
Welches Problem sehe ich nicht? Das sieht aus, wie das, was in der anderen Datei drin ist. Habe ich damals doch keinen Unfug gemacht?
Wie schon erwähnt, probier das Entpacken mal mit dem graphischen File Roller.
Da kommt Archivformat nicht unterstützt - musst Du Dich an die Entwickler von File-Roller wenden. | tar -tjf archiv.bz2
./d.html/
./d.html/f.html/
./d.html/f.html/test.html
./d.html/f.html/test.txt
./d.html/test.html
./d.html/test.txt
./d.html/e/
./d.html/e/test.html
./d.html/e/test.txt
|
Mit tar -xjf archiv.bz2 packt man es aus. Nenn die Datei (bei der Erzeugung) archiv.tar.bz2, dann begreift es auch Dein komischer Roller.
| t201:~/proj/mini/forum/test/foo > find B
B
B/C
B/C/a3.txt
B/C/a1.txt
B/Bild1.jpg
t201:~/proj/mini/forum/test/foo > find -mindepth 2 -maxdepth 2
./B/C
./B/Bild1.jpg
|
Tiefe 0 ist der Punkt. Tiefe 1 ist B.
In Tiefe 0 sucht find aber nichts; mit -mindepth 0 fängt find erst ab der Tiefe 1 mit dem Suchen an. Im Parkhaus finde ich jedoch in Tiefe 0 schon viele Autos, wenn ich danach suche. Die Logik von find entspricht also nicht dem gewöhnlichen Sprachgebrauch, wo man schon in Tiefe 0 suchen und was finden kann. Auf diesen Umstand sollte man IMHO deutlich und unmissverständlich hinweisen.
Wieso Parkhäuser oder auch Tiefgaragen kein gutes Beispiel sind, hatten wir schon, oder? Weil Tiefgaragen keine Tiefgaragen beinhalten. Tiefe 0 ist auch kein Sprachgebrauch für Tiefgaragen, soweit ich das als Radfahrer beurteilen kann.
Dass der Startpunkt selbst gefunden wird ist halt dem überraschenden Umstand zu schulden, dass find , wenn es Deiner Schreibe gemäß in einem Verzeichnis sucht, nicht nur das findet, was sich im Verzeichnis befindet.
Um Deinen lustigen Beispielen mit einem sinnvolleren zu kommen: "Suche alles graue im Karton!" Der Karton kann leer sein, kann einen oder mehrere kleinere Kartons enthalten sowie sonstiges Zeuch. Jetzt kann man streiten, ob die Innenwand des Kartons, die zweifelsfrei grau ist, im Karton ist. Aber wie zu Beginn meiner Antwortserie bereits gesagt: Nicht für alles findet man gute Analogien. Wieso das aktuelle Verzeichnis im Normalfall in den Suchergebnissen auftaucht erschließe ich mir so: Wenn nichts besonderes angegeben ist, sucht man da, wo man gerade ist.
Ob man find -name "d*" oder find . -name "d*" sagt soll das gleiche Resultat ergeben. Statt als Startverzeichnis eine ordinäre Datei zu wählen kann hilfreich sein, wenn man diese auf viele Parameter untersuchen will: find -foobar.txt -size +5M -mtime -9 ... . Wenn man mit | find a -maxdepth 1
a
a/d.html
a/a.html
a/archiv.tar.bz2
a/cur
|
findet, dann ist es nicht unlogisch mit
das gleiche zu finden.
Der Vergleich passt nicht, weil eine Ebene immer nur Autos enthält und nicht weitere Ebenen. Und weil Du immer nur Autos suchst, nicht Ebenen.
Den Aspekt hatte ich hier weggelassen. Den Vergleich mit der vollständigen Situation hatte ich schon mal in 8780638 anhand einer Tiefgarage – wo Tiefe besser passt, als im Parkhaus – mit ebenerdiger Startebene (Parkplatz) dargestellt.
Ebenen enthalten auch in Tiefgaragen keine Ebenen. Auch in Tiefgaragen sucht man nur Autos, nicht Ebenen.
Es gibt keine leeren Kapitel, usw.
Als künstlerischer Effekt ist auch ein unbeschriebenes, also leeres Kapitel denkbar.
Es gibt keinen etablierten Sprachgebrauch zur Suche von leeren Kapiteln, Kapiteln variabler Tiefe in anderen Kapiteln usw.
Aus der Nichtexistenz kann also nichts gefolgert werden.
sucht nach den vollständigen Namen hausarbeit.odt.
Hm. hier sucht find also ausnahmsweise mal nach Namen, und nicht nach Dateien.
Falsche Dichotomie. Dass nach dem Namen gesucht wird heißt nicht, dass nicht nach der Datei gesucht wird.
find -name hausarbeit.odt Hier wird mit dem Namen gesucht. Ist das wirklich erklärungsbedürftig?
Also was denn nun, mit oder nach Namen?
Ja.
😀 Da sonst im ganzen Artikel nach Dateien gesucht wird klingt diese Unterscheidung für mich hier dann nach "sucht nach Namen in Dateien", also das, was eigentlich nur grep kann.
Hausarbeit klein und .odt und Du meinst dann, es sucht nach Wörtern in der Datei? Nein, nicht nach Wörtern, nach Namen!
In dem Zusammenhang, dass wir festgelegt haben, dass find eine Instanz zur Dateisuche und nicht zur Namenssuche ist, klingt obiger Satz halt wie "Der Tierfotograf sucht nach vollständigen Organen Affe" ... statt nach Tieren die Affen sind.
Soll da eine Art Logik jetzt am Werk sein? Die Datei hausarbeit.odt kann man auch mit der Dateigröße, dem Dateidatum usw. suchen. Den Namen braucht man nicht suchen, den kennt man schon, er lautet "hausarbeit.odt". Da ich Dich mit Beharrlichkeit davon abgebracht habe ständig vom Aufsuchen zu reden habe ich vielleicht auch Chancen zu vermitteln, dass Dateien gesucht werden, nicht Namen.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb:
Tut mir leid, wenn das so wirkt. Habe ich aber nur ausnahmsweise so gemacht, sonst frage ich doch immer erst langwierig hier im Forum nach, solange ich es nicht für eine Bagatelle halte.
Nein, Du hast nicht ausprobiert und gefragt, wie das Archiv gepackt und entpackt wird, sondern geändert. Du hast nicht probiert, was die md5sum-Kommandos machen und nicht gefragt, sondern geändert. Du hast überall "ab Verzeichnis" geschrieben, hast überall zu Dateinamen(seinträge) geändert usw.
Und Du begründest Deine Änderung erst, nachdem sich jemand beschwert.
Immerhin schreibe ich ein wenig mehr als das berühmte 'm'.
Soll ich jetzt applaudieren?
So komme ich immer in die aggressive Rolle, aber von mir aus.
Wäre das nicht eher die defensive (verteidigende) Rolle?
Nein. Du begründest ja nicht, wieso Du etwas schlecht fandest, sondern änderst und überlässt es mir, den Konflikt zu suchen.
man find:
Im Kontext der Suche einer Datei im Dateisystem hat eine Datei sehr wohl eine Tiefe.
Nein doch, sie hat keine Tiefe, sondern befindet sich in Tiefe x im Verzeichnisbaum (depth in the directory tree).
Sehr oft, die Betonung liegt auf sehr, erwarten Programme die Dateien nicht irgendwo, sondern an einer ganz bestimmten Stelle im Dateibaum. Angefangen bei den ausführbaren Dateien selbst, bei Libraries, bei Konfigurationsdateien, bei Dokumentationen, Icons, und, und, und. Wenn die Datei /etc/passwd nicht in /etc ist, sondern in ~, dann ist es keine wichtige Systemdatei mehr sondern ein Haufen Sperrmüll, ein Klump. Eine .doc-Datei die Du mit LibreOffice bearbeitest kann ruhig hier oder dort oder 3 Ebenen tiefer liegen (solange es keine Kollision mit einer Datei gleichen Namens dort gäbe, Lese- und Schreibrechte im Ordner). Der Ort wo die Datei liegt ist eine ganz wichtige Eigenschaft der Datei.
Im November oder Januar habe ich schon mal geschrieben, dass "ab" im Kontext von Ästen und Knoten eine gute Wahl sein kann.
Also für einen Startpunkt ist "ab" ok, wenn der ein Verzeichnis ist und als solches benannt wird, nicht mehr? Wenn der User aber ein Verzeichnislisting gewohnt ist wie:
| bin
boot
dev
etc
home
lib
mnt
opt
...
|
"ab etc" als "etc, home, lib, ..." gedeutet werden kann.
Klar kann man das so missverstehen, halte ich aber für unrealistisch, und erst recht, wenn wir im "unbenamten" aktuellen Verzeichnis . starten. Außerdem wissen wir, dass find zunächst mal in die Tiefe geht, und eben nicht in die Startebene.
Selbst Mac- und Windowsuser suchen in Verzeichnissen, nicht ab Verzeichnissen. Hör Dich um. Lies in Foren. Ich habs korrigiert.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb: user_unknown schrieb: Das ist falsch. löscht auch Verzeichnisse, die nicht leer sind.
Dann habe ich wohl falsch verstanden, was unter rm --help zu lesen steht: -d, --dir leere Verzeichnisse werden entfernt
Warum wird da "leere" betont, wenn auch volle gelöscht werden?
Probiers halt aus (in einem Testverzeichnis, von mir aus auch Startverzeichnis oder ab einem solchen). 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | t201:~/proj/mini/forum/xx > find d.html/
d.html/
d.html/f.html
d.html/f.html/archiv.bz2
d.html/f.html/test.html
d.html/f.html/test.txt
d.html/archiv.bz2
d.html/test.html
d.html/test.txt
d.html/e
d.html/e/archiv.bz2
d.html/e/test.html
d.html/e/test.txt
t201:~/proj/mini/forum/xx > rm -dr d.html/
t201:~/proj/mini/forum/xx > find d.html
find: "d.html": Datei oder Verzeichnis nicht gefunden
|
Du darfst nicht Dinge beweisen wollen, die gar nicht strittig sind. Das strittige Kommando war rm -dr und -r steht für rekursiv, und offenbar arbeitet rm -dr auch depth-first, so dass die Verzeichnisse leer sind, wenn sie an der Reihe sind, und dann können sie gelöscht werden.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Der User rafi hat einen neuen Abschnitt eingefügt: Ausgabe von find alphanumerisch sortieren
was nichts mit find zu tun hat - man kann mit piping und sort jede Ausgabe sortieren. Ich schlage vor zur Vorversion zurückzurollen. Der find-Artikel ist schon lang genug und der Artikelaufbau durchdacht, wird aber hier gestört.
|
rafi
Anmeldungsdatum: 7. Februar 2006
Beiträge: 1050
Wohnort: Baden-Baden
|
user_unknown schrieb:
was nichts mit find zu tun hat ...
neja, es gibt Suchprogramme die intern bereits Sortieralgorithmen haben, und oftmals ist es sinnvoll die Ergebnisse geordnet zu bekommen, zB wenn man den Output drucken will oder eine Dokumentation schreibt. Eine Alternative wäre mit einem Hinweis auf die Seite https://wiki.ubuntuusers.de/sort/ linken. Möchte man die Suchergebnisse sortiert angezeigt bekommen, so lässt sich die Ausgabe mit sort pipen. Dies wird hier gezeigt
|