UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
noisefloor schrieb: _Bitte_ das nächste mal für so was nächstes Mal kurz eine Baustelle beantragen und dann da gezielt die Edits machen. Zumal bei einer Baustelle dann auch Zeit für eine Diskussion ist und möglichen "Hot-Fixes" notwendig sind.
Gute Idee!
Also bitte den Artikel in eine Baustelle verschieben, ich habe da noch ein paar Veränderungen auf Lager ... aktuell gerade ein offenes Edit-Fenster. Kann ich das noch kurzfristig posten, oder soll ich besser auf die Baustelle warten?
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: "Alles" im Sinne von alle neuen Vorkommnisse von "und Unterverzeichnisse"? Das würde ich begrüßen. Ansonsten sind ja viele Änderungen von Dir auch in meinem Sinne Verbesserungen.
Vor ein paar Stunden begann ich, die Änderungen vorzunehmen, doch da kam mir ein längerer Anruf dazwischen. Jetzt sind sie fertig, doch aufgrund der Intervention von noisefloor will ich sie nun mal erst nicht posten und auf seine Antwort warten. Mir fallen 6 unterschiedliche Formulierungen auf:
Es wird nach Dateien gesucht ... Suche nach allen Dateien ... Suche nach Dateien ... Sucht Dateien ... Nach Dateien suchen ... Beginnt die Suche ...
Wie wäre es, da eine Vereinheitlichung vorzunehmen? 1., 2., 5. und 6. gefallen mir nicht wirklich. Die Unterscheidung der beiden anderen macht vielleicht Sinn, wenn man 3. vor und 4. nach dem Syntaxmuster/Beispiel verwendet. Welche Formulierung würde Dir am besten gefallen? Das "Ei des Kolumbus" könnte vielleicht folgendes Schema sein, damit kämen wir elegant aus der Zwickmühle der Ungenauigkeit von "Datei" und es ist zudem schön kompakt: -mtime n | Sucht nach allem, was zwischen n und n+1 Tage alt ist.
Leider habe ich mit dem Wikivergleich von Versionen, der eigentlich schon recht gut ist, immer das Problem nicht gut erkennen zu können, was jetzt die jüngere und was die ältere Version ist. So habe ich beim Überfliegen aller Änderungen und der Inspektion einiger Änderungen schon gedacht: "Hey, das war doch früher viel besser formuliert!" um dann zu sehen, dass ich es falsch zugeordnet habe, und die bessere Version die neuere ist.
"Shit happens" 😉 ich orientiere mich an rot=schlecht=gelöscht=alt und grün=gut=neu. Ist auch die gleiche Reihenfolge, wie man es von normalen Diffs gewohnt ist.
Eine Verbesserung ganz in meinem Sinne war etwa "Werden Platzhalter verwendet, ..." statt des gestelzten "Sollten Platzhalter verwendet werden, ..." - das wäre eine Verbesserung die von mir sein könnte, aber von Dir ist. ☺
Danke für dieses und die anderen Komplimente.
Meine Ansicht ist, dass der Artikel v.a. für die Leute ist, die zum ersten Mal find benutzen, oder zum ersten Mal ein wenig tiefer bohren wollen. Er soll die Anfänger auf nützliche Features neugierig machen und darf deshalb exotische Anwendungen verschweigen. Es soll kein Ersatz und keine Übersetzung der Manpage sein.
...
Aber wenn man hier kunstvoll von Objekten redet hält einen der Leser für einen verschrobenen Nerd, oder man muss es soweit klären, dass man auf Pipes und Sockets hinweist, aber dann muss man die erklären. Nur schreckt sowas halt ab, weil dann leicht der Eindruck entsteht, man müsse das erstmal verstanden haben um find zu benutzen und das schreckt die meisten wohl ab.
Gut ausgedrückt, sehe ich auch so.
Wenn Du mir in einem Satz erklären kannst, was äquivalente Objekte sein sollen, dann mach es, und schreib es rein. Wenn es ausufert und ein unverständliches Kauderwelsch mit einem anderen, unverständlichen Kauderwelsch erklärt wird sage ich: Lieber weglassen.
Wie findest Du denn folgende Formulierung für die einmalige Verwendung im Einführungsabsatz? : Da unter unixoiden Systemen der Leitsatz "Alles ist eine Datei" gilt, werden auch Verzeichnisse und andere [äquivalent beschriebene] Ziele wie Sockets, named Pipes etc. gefunden.
Da die Leser weder wissen, dass die Formulierung von Dir ist, noch, dass Du Deine eigene Vorstellung davon hast, was sie bedeuten soll, ist äquivalent einfach schlecht. 2+2 ist äquivalent mit 4, in der Mathematik.
Meine Vorstellung war diese: Die Adressierung/Syntax von Dateien und Verzeichnissen ist äquivalent mit der von Sockets und ... . Ich verstehe aber Deine Einwände.
☺ Weiß ich nicht mehr genau. Jedenfalls kann man es nicht in jedem Absatz wiederholen, um möglichen Fehlern vorzubeugen.
Da stimme ich Dir zu. Die noch bestehenden Wiederholungen wo es nur geht zu bereinigen stand auch schon auf meiner Agenda.
Klammern im Fließtext sind unschön.
Hatte ich von "Startverzeichnis(se)" übernommen. Für die Überschrift "Pfad(teile)" fände ich es deshalb OK, doch im darauffolgenden Satz kann man es vermeiden. Der Begriff Dateitrenner macht mir auch Bauchschmerzen.
Im Englischen ist "file separator" zur Unterscheidung vom "path separator" ':' ein gängiger Terminus. Vorschlag: Verzeichnisnamen suchen
Das macht doch schon -name . Für -path finde ich die direkte deutsche Übersetzung klarer. Sucht man nach Verzeichnisnamen im Ast zur Datei, kommt man mit -name nicht weiter. Mit -path kann man nach Namen und Namensteilen suchen, die im Pfad zur Datei vorkommen:
Warum einen weiteren Begriff "Ast" einführen, Pfad meint doch dasselbe? "... kann man nach Namen und Namensteilen suchen ..." empfinde ich als redundante Verdopplung aus dem ersten Satzteil. Wie wär's mit: Will man mittels Pfaden oder Teilen davon suchen, kommt man mit -name nicht weiter. Das Suchkriterium -path ist hier die Lösung, denn es erlaubt die Verwendung des Dateitrenners/Zeichens / .
War kein spezieller Wink. Die Idee ist nur, man stellt mtime als exemplarischen und womöglich häufigst gebrauchten Fall etwas näher vor, und wen es interessiert, der wird den Transfer zu ctime und atime selbst hinbekommen, die man nur als weitere Optionen nennt.
Zustimmung! Deshalb hatte ich auch schon erwogen, die Reihenfolge der Erwähnung zu ändern. Auch -Xtime ist sicher geläufiger als -Xmin . Für -Xtime n gilt die Zeitspanne n .. n+1 , was ich intuitiv finde, doch beim Rumprobieren habe ich rausgefunden, dass zumindest für -amin n merkwürdigerweise n-1 .. n gilt. Das fände ich einen weiteren Grund, -Xmin nachrangig aufzuführen und da auf diese Nicht-Intuitivität hinzuweisen. (Das war übrigens der Hauptgrund, warum ich mich mit der Verbesserung des Artikels beschäftigen wollte, bin dann aber erst über die "einfacheren" Dinge hergefallen, da ich noch nicht dazu kam, dieses Phänomen und das der Auf- und Abrundung umfassend zu untersuchen, weshalb ich meine anfängliche diesbezügliche Änderung erst mal wieder zurücknehmen musste, ich werde aber darauf noch zurückkommen.) Auch -name ist sicher geläufiger als die Zeitsuchkriterien. Deshalb würde ich folgende Reihenfolge vorschlagen: -name DATEI, -iname DATEI, -type T, -mtime n, -mtime +n, -mtime -n, -ctime n, -atime n, -mmin n, -newer DATEI, -user BENUTZER, -nouser, -nogroup, -size n[cwbkMG], -maxdepth n, -depth
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb:
Mir fallen 6 unterschiedliche Formulierungen auf:
Es wird nach Dateien gesucht ... Suche nach allen Dateien ... Suche nach Dateien ... Sucht Dateien ... Nach Dateien suchen ... Beginnt die Suche ...
Wie wäre es, da eine Vereinheitlichung vorzunehmen?
Es gibt Fälle, da empfiehlt es sich, eine einheitliche Bezeichnung zu benutzen. Hier sehe ich dazu keinen Anlass und daher eher Grund für Abwechslung.
Das "Ei des Kolumbus" könnte vielleicht folgendes Schema sein, damit kämen wir elegant aus der Zwickmühle der Ungenauigkeit von "Datei" und es ist zudem schön kompakt: -mtime n | Sucht nach allem, was zwischen n und n+1 Tage alt ist.
Datei ist nicht ungenau. Allem ist es. Logeinträge, die soundso alt sind, werden nicht gefunden, Datenbankeinträge, wenn später weitere ergänzt wurden.
"Shit happens" 😉 ich orientiere mich an rot=schlecht=gelöscht=alt und grün=gut=neu. Ist auch die gleiche Reihenfolge, wie man es von normalen Diffs gewohnt ist.
Hängt aber davon ab, bei welcher Spalte man den Radiobutton markiert hat, oder? Ich bin leicht farbenblind, und muss immer überlegen ob das Dunkelrot grün ist oder das Hellrot. ☺ Ich vermute im Einleitungstext ist die Hervorhebung in korrespondierenden Farben gehalten (hier nicht farblich markiert:)
Die folgende Tabelle zeigt die Änderungen im Artikel „find“ zwischen Revision 29. August 2016 13:00 (Begriffe verwechselt, Pfadtrenner wäre ':') und Revision 29. August 2016 12:34 (noch lesbarer) auf.
aber ob die Farben identisch sind kann ich nicht sagen.
Wenn Du mir in einem Satz erklären kannst, was äquivalente Objekte sein sollen, dann mach es, und schreib es rein. Wenn es ausufert und ein unverständliches Kauderwelsch mit einem anderen, unverständlichen Kauderwelsch erklärt wird sage ich: Lieber weglassen.
Wie findest Du denn folgende Formulierung für die einmalige Verwendung im Einführungsabsatz? : Da unter unixoiden Systemen der Leitsatz "Alles ist eine Datei" gilt, werden auch Verzeichnisse und andere [äquivalent beschriebene] Ziele wie Sockets, named Pipes etc. gefunden.
Immer noch nichts. Ich habe einmal aus einem Beispiel etwas mit Named Pipes abgetippt, ausprobiert, beschlossen sowas nie zu brauchen und wieder vergessen. Sockets such ich auch nie. Wozu den User mit was behelligen, was ihn höchstwahrscheinlich nicht juckt? Um ihm zu erklären, dass er es nicht braucht? Auch Verzeichnisse sind Datein und werden deshalb wie diese behandelt - Punkt. Das ist knapp und wahr. Nur der Kultur halber wäre es schön, wenn das Schlagwort "Alles ist eine Datei" mal erwähnt würde. Wie ist: Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch Verzeichnisse Dateien sind, und nach den gleichen Kriterien gefunden werden.
Klammern im Fließtext sind unschön.
Hatte ich von "Startverzeichnis(se)" übernommen. Für die Überschrift "Pfad(teile)" fände ich es deshalb OK, doch im darauffolgenden Satz kann man es vermeiden.
Wo wir schon dabei sind: Vorgabe: Und-Kombination, die Funde müssen alle Kriterien erfüllen
| find -mindepth 3 -maxdepth 5
|
Finde ab Unterverzeichnis(se) 3 (mindepth 3) UND bis Unterverzeichnis(se) 5 (-maxdepth 5).
Weiters Beispiel der UND-Kombination:
| find -mindepth 3 -type f -name "*.avi" -size +5M
|
Beginnt die Suche ab Unterverzeichnis(se) 3 (-mindepth 3), UND findet nur gewöhnliche Dateien (-type f), die die Endung .avi besitzen UND mindestens 5 MB groß sind (-size +5M).
Auch ohne die Klammern ist das einfach gräßlich und sinnlos (aber eine ältere Änderung, nicht von Dir): Finde ab Unterverzeichnisse 3 (mindepth 3) UND bis Unterverzeichnisse 5.
Soll das ein Satz sein? In welcher Sprache? Deutsch ist es sicher nicht. Da stand mal: find -maxdepth 5 -mindepth 3 steigt bei der Suche 3-5 Verzeichnisebenen herab.
Ich schlage vor das zu restaurieren.
Der Begriff Dateitrenner macht mir auch Bauchschmerzen.
Im Englischen ist "file separator" zur Unterscheidung vom "path separator" ':' ein gängiger Terminus.
Wie oft hörst oder liest Du Dateitrenner?
Vorschlag: Verzeichnisnamen suchen
Das macht doch schon -name . Für -path finde ich die direkte deutsche Übersetzung klarer. Sucht man nach Verzeichnisnamen im Ast zur Datei, kommt man mit -name nicht weiter. Mit -path kann man nach Namen und Namensteilen suchen, die im Pfad zur Datei vorkommen:
Warum einen weiteren Begriff "Ast" einführen, Pfad meint doch dasselbe? "... kann man nach Namen und Namensteilen suchen ..." empfinde ich als redundante Verdopplung aus dem ersten Satzteil.
Ja, Pfad ist besser, weil er ../../foo/bar besser erfasst. Ast war keine so gute Idee.
Wie wär's mit: Will man mittels Pfaden oder Teilen davon suchen, kommt man mit -name nicht weiter. Das Suchkriterium -path ist hier die Lösung, denn es erlaubt die Verwendung des Dateitrenners/Zeichens / .
Ich weiß nicht, was Du mit Deinem Dateitrenner hast. ☺ Für die Option -path ist es ein Zeichen wie die anderen Zeichen auch. Besonders ist hier doch, dass man nach Mustern im Pfadnamen zu der Datei suchen kann, nicht nur nach dem Dateinamen.
Mit -path kann man nach Mustern im Pfadnamen zur Datei suchen, nicht nur nach dem Dateinamen selbst.
Zustimmung! Deshalb hatte ich auch schon erwogen, die Reihenfolge der Erwähnung zu ändern. Auch -Xtime ist sicher geläufiger als -Xmin . Für -Xtime n gilt die Zeitspanne n .. n+1 , was ich intuitiv finde, doch beim Rumprobieren habe ich rausgefunden, dass zumindest für -amin n merkwürdigerweise n-1 .. n gilt. Das fände ich einen weiteren Grund, -Xmin nachrangig aufzuführen und da auf diese Nicht-Intuitivität hinzuweisen. (Das war übrigens der Hauptgrund, warum ich mich mit der Verbesserung des Artikels beschäftigen wollte, bin dann aber erst über die "einfacheren" Dinge hergefallen, da ich noch nicht dazu kam, dieses Phänomen und das der Auf- und Abrundung umfassend zu untersuchen, weshalb ich meine anfängliche diesbezügliche Änderung erst mal wieder zurücknehmen musste, ich werde aber darauf noch zurückkommen.)
Tja - wenn Du da was ändern willst musst Du Dich schlau machen. Ich will das nicht nochmal untersuchen. ☺
Auch -name ist sicher geläufiger als die Zeitsuchkriterien. Deshalb würde ich folgende Reihenfolge vorschlagen: -name DATEI, -iname DATEI, -type T, -mtime n, -mtime +n, -mtime -n, -ctime n, -atime n, -mmin n, -newer DATEI, -user BENUTZER, -nouser, -nogroup, -size n[cwbkMG], -maxdepth n, -depth
Will man nach Häufigkeit vorgehen, dann müsste wohl size auch vor user. Die Zeitformen will man ja sicher zusammenhalten. Eine starke Meinung habe ich da nicht. Populäre Möglichkeiten vorzuziehen bringt den Leser eher auf die Idee, das Programm könnte für ihn interessant sein, also bin ich eher dafür.
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Ich schließe mich in meinen zwei zum Kommentieren gewollten Punkten (Abwechslung der Sprache, Pipes), aber auch gleich dem ganzen Posting von user_unknown an - und ergänze: -amin n bedeutet nicht n-1 ... n, sondern exakt n. Will man bis n, schreibt man -n, will man über n, schreibt man +n. Genauso wie bei mmin auch.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Benno-007 schrieb: Ich schließe mich in meinen zwei zum Kommentieren gewollten Punkten (Abwechslung der Sprache, Pipes), aber auch gleich dem ganzen Posting von user_unknown an
user_unknown hatte jeweils vor und nach meinen Einwänden teilweise unterschiedliche Standpunkte. In welchen Punkten schließt Du Dich also welchem Posting an? 😉
-amin n bedeutet nicht n-1 ... n, sondern exakt n.
Demnach sollten also auch bei allen anderen Zeit-Vergleichen Ausdrücke wie "n+1", "n*24h" - die übrigens nicht von mir sind, sondern schon lange so da stehen - ersetzt werden ??? Dachte ich auch erst mal, aber ... Wenn jetzt Mittwoch Mittag ist, und am Montag um 2 h Klaus und um 20 h Petra geboren wurden, wie alt sind denn dann Klaus und Petra Deinem Verständnis nach? Wenn heute Mittwoch Mittag KW 35 ist und Dein Kollege fragt Dich nach Dateien, die exakt 30 Wochen alt sind, was gibst Du ihm dann? :
die Dateien von Mo - So aus KW 5 die Dateien von Do KW 4 - Mi KW 5 die Dateien von Mi KW 5 - Di KW 6 nur die Dateien von Mi KW 5 gar keine, denn es gibt keine Datei von Mi KW 5 12:00:00 h oder noch was anderes
Und wenn er "exakt" weglassen würde, könnte er evtl. auch noch die Dateien von KW 1 - 9 meinen.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Da das mit der Baustelle wohl nichts wird und ich in meinem Kopf auch wieder Platz für andere Dinge brauche, poste ich mal weitere Änderungen, um sie mit user_unknown (und selbstverständlich auch anderen) begucken und bewerten zu können.
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Ich bezog mich nur auf sein letztes Posting - und nur auf amin. Bei anderen Optionen gibt es in der man durchaus abweichendes Verhalten, welches z.B. bei einem Tag alt sinnigerweise auch eine Zeitspanne meinen kann.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Benno-007 schrieb: ... und nur auf amin. Bei anderen Optionen ... bei einem Tag alt sinnigerweise auch eine Zeitspanne meinen kann.
Bist Du sicher, dass -amin im Gegensatz zu -atime nur einen Zeitpunkt meint, also mit -amin 1 um 12:01:30.34567 nur 12:00:30.34567, nicht aber weder 12:00:00.00000 noch 12:00:30.00000 gefunden werden?
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Als Gedankenstütze bzw. Erklärung würde ich noch files u. directories dazuschreiben.
-type f
Es wird nur nach regulären Dateien gesucht. Sucht nur nach regulären Dateien. Sucht nur nach regulären Dateien (files).
-type d
Es wird nur nach Verzeichnissen gesucht. Sucht nur nach Verzeichnissen. Sucht nur nach Verzeichnissen (directories).
Unter Windows hat sich ja wohl inzwischen Folder bzw. Ordner etabliert.
Sucht erst rekursiv in der Tiefe, also im Inhalt von Verzeichnissen bevor das Verzeichnis selbst untersucht wird.
Tiefe hat keinen Wert, der über Inhalt hinausgeht, also schlage ich vor das zeremoniell zu opfern. Zur Buße fügen wir einen Genitiv hinzu (bin Mitglied des Geheimordens zu dessen Rettung). Außerdem ist hier der Begriff Unterverzeichnis mal angebracht: Sucht erst rekursiv im Inhalt der Unterverzeichnisse, bevor das Verzeichnis selbst durchsucht wird. Untersucht wäre passender, wenn mit -type d gesucht würde, daher hier durchsucht. Das schlimme ist, je länger und öfter man draufschaut, umso mehr findet man. Lass uns schnell machen! ☺ Am Ende wirdd einem dann nur noch wuschig und man versteht keinen deutschen Satz mehr, ohne dass sich die Haare zu Berge sträuben.
Sucht Dateien die n Zuordnungseinheiten belegen. Folgende Endungen können zusätzlich verwendet werden: c für Bytes, w für Zwei-Byte-Wörter, b für 512-Byte-Blöcke (Standard), k für KiB (Kibibyte), M für MiB, G für GiB.
Ack.
Außer "zusätzlich" und "Endungen". Das geht doch besser! Das sind keine Endungen, sondern Marker. Oder Kürzel. Einheitskürzel oder Maßeinheiten und die können verwendet werden (müssen aber nicht), also ohne zusätzlich.
Sucht Dateien die n Zuordnungseinheiten belegen. Folgende Maßeinheiten können verwendet werden: c für Bytes, w für Zwei-Byte-Wörter, b für 512-Byte-Blöcke (Standard), k für KiB (Kibibyte), M für MiB, G für GiB.
Bei Mimmimibytes sitze ich zwischen den Stühlen. Einerseits verwendets fast niemand, andererseits ist es ja ganz richtig. Na, am Ende gehen wir eh alles noch mal Wort für Wort durch. ☺ Zur Zeitdebatte: Erst muss man rausfinden, was das Programm unter -xy 5 versteht, dann kann man es erklären. Und, oh Graus, find hält hier weitere Subtilitäten bereit, Zitat man find:
| -daystart
Measure times (for -amin, -atime, -cmin, -ctime, -mmin, and -mtime) from the beginning of today rather than from 24 hours ago. This option only
affects tests which appear later on the command line.
|
Will man das darstellen? Ich meine nein. Es geht mehr darum die Leute zu ermuntern, find zu benutzen, und aufzuzeigen, welch vielfältige Möglichkeiten es gibt, als die Leute mit allen Feinheiten zu erschlagen. Die Aussagen sollten aber den Defaultfall korrekt darstellen. Eine Datei die 5 Tage alt ist, ist nicht 4 und auch nicht 6 Tage alt, aber eben auch nicht genau 5 Tage alt (und 0 Stunden).
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Noch ein Wort zur Baustelle. Die ist doch v.a. sinnvoll, wenn man große Blöcke austauscht/verschiebt, Kapitel löscht und auslagert, so dass der Artikel zwischenzeitlich unbenutzbar ist. Nicht bei iterativen Veränderungen, die alle mehr oder weniger brauchbar sind. 100 Änderungsnotizen alle 5 Minuten sind natürlich furchtbar, wenn man später die Änderungshistorie durchsucht, zumal wenn die Änderungsnotiz so unspezifisch ist, dass man diese auch mit Glück nicht finden kann. Je kleiner die Änderung ist, desto präziser kann man sie in der Notiz darstellen. Beispiel: In der Revision vom 29. August 2016 00:42 wurde nur die Klammer mit teile eingefügt:
== Pfad(teile) ==
Wobei das irgendwie seltsam ist. Wenn ich die 2 benachbarten Versionen markiere, | 29. August 2016 00:42 : m Befehlsformat 906188
29. August 2016 00:18 : Hinweis auf Suche im gesamten Verzeichnisbaum und Beseitigung von Redundanzen und Halbheiten 906183
|
Dann ist der Unterschied zwischen diesen doch "m Befehlsformat", unabhängig davon, welche ich als erstes markiere? Was hat das mit Befehlsformat zu tun? Nun, egal, man schaut sich Versionshistorie an, und braucht die Notiz, um ohne alle Vergleiche durchzuführen erahnen zu können, wo was geändert wurde. Wildcard-Hinweis verschlankt das ist schon aussagekräftige. Oder Änderung, da "-maxdepth 0" nichts findet und "-maxdepth 1" nur im aktuellen Verzeichnis sucht - wenn ich den Täter suche, der das -maxdepth-Flag verbockt hat - hier werde ich vielleicht fündig. Wo und was. Man muss sicher selbst ein paar mal nach Änderungen gesucht haben, um den Wert einer aussagekräftigen Zusammenfassung zu verstehen. ☺ Wir brauchen vielleicht doch ein Karmasystem, und für jedes m-Edit im Wiki gibt es 100 Punkte Abzug, auf Verdacht. 😉 M ist Mist. Wer Kommafehler oder nähmlich mit h schreibt, der verrät nämlich denen, die was anderes suchen, dass es das hier nicht gibt. Befehlsformat kann im ganzen Artikel vorkommen. Welcher Befehl?
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
und für jedes m-Edit im Wiki gibt es 100 Punkte Abzug, auf Verdacht. 😉
Da hätten manche Ex-Wiki-Teamleiter locker paar 100.000 Minus. UlfZibis schrieb: Benno-007 schrieb: ... und nur auf amin. Bei anderen Optionen ... bei einem Tag alt sinnigerweise auch eine Zeitspanne meinen kann.
Bist Du sicher, dass -amin im Gegensatz zu -atime nur einen Zeitpunkt meint, also mit -amin 1 um 12:01:30.34567 nur 12:00:30.34567, nicht aber weder 12:00:00.00000 noch 12:00:30.00000 gefunden werden?
-amin 1 heißt exakt zur selben Minute oder gar Sekunde? Sonst brauchst du +/- davor. Wenn es nur um 1 min geht, könnte es tatsächlich Überschneidungen der Varianten 1/+1/-1 geben. Und tatsächlich: 1 und -1 kommt auf dasselbe Suchergebnis einer eben angelegten Datei, +1 nicht. Und hab mit date herausgefunden, dass die Minute 60s meint, also tatsächlich von 12:01:30 bis 12:02:30 (29) gilt. Ubuntu Phone Terminal sei dank. 😉
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Hallo user_unknown, danke für die weiteren Anregungen. Ich möchte allerdings erst mal das schon angesprochene abarbeiten außer ... schrieb: Erst muss man rausfinden, was das Programm unter -xy 5 versteht, dann kann man es erklären.
Genau dazu fiel mir schon zu Beginn auf, dass find , find . und find * nicht dasselbe sind, und was mich schwer irritierte:
findet z.B. .
./V2
./V1
./V1/Datei1_1
findet aber nur V2
V1
V1/Datei1_1 Man könnte also denken, dass ohne * auch ".." durchsucht wird, um "." zu finden. Weiterhin findet nichts, während find * -maxdepth 0 -size 1 das findet: Datei0_1
Aber findet . während alles andere findet: Datei0_1
V1
V1/Datei1_1
V2 * hebt also den Suchstart auf den Inhalt des aktuellen Verzeichnisses, lässt also das aktuelle Verzeichnis selbst aus.
Daraus ergibt sich also:
find sucht ab dem aktuellen Verzeichnis, findet also auch . (also nicht nur im aktuellen Verzeichnis, wie bisher im Wiki steht). find * sucht nur im aktuellen Verzeichnis (also unter Auslassung des aktuellen Verzeichnisses selbst).
find foo sucht ab dem Verzeichnis foo.
Kannst Du dem so folgen?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
Es gibt kein find * . Das * wird schon von der Shell erweitert (und dann normalerweise eben ohne . .. .*). Das wird speziell bei find irgendwie zu oft vergessen, obwohl es auf der Wikiseite auch unter "typische Fehler" aufgelistet ist. Und in der Manpage steht: If no starting-point is specified, '.' is assumed. -maxdepth 0 findet nur den Startpunkt, also . , oder eben die angegebenen Startpunkte...
. ist ein Verzeichnis und ./V1 dann schon eine Ebene unter diesem Verzeichnis (depth 1).
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
frostschutz schrieb: Es gibt kein find * . Das * wird schon von der Shell erweitert (und dann normalerweise eben ohne . .. .*).
Das ist richtig, erlaubt mir aber . von den Suchergebnissen auszuschließen. Genau das wollte ich damals, und so bin ich drauf gekommen. Interessant ist damit auch, dass -maxdepth 0 so auch Dateien listet:
find Datei0_1 -maxdepth 0
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
@ Ulf: Klingt für mich alles nachvollziehbar so, aber wenn es das für dich nicht ist, wäre das jetzt etwas mühsig, das zu erklären. Sollte aber auch im Artikel nicht der Schwerpunkt sein, solche Detaildiskussionen.
|