user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
UlfZibis schrieb: user_unknown 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 ...
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.
Wärest Du denn damit einverstanden, zumindest die ersten beiden zu entsorgen. 1. weil lang und geschwurbelt und 2. weil da die Frage aufkommen könnte: "Warum der Unterschied zw. der 2. und 3. Form?"
Jetzt ist es weg, jetzt kann es auch weg bleiben. Ich meine, der Leser liest den Artikel, er untersucht ihn nicht. Missverständnisse kann man nie ganz ausschließen aber das oben verleitet m.El. nicht zu solchen und geschwurbelt ist es auch nicht (ist ja von mir, oder? ☺ ). Mein Herz hängt aber nicht dran also lass es wie es jetzt ist.
Logeinträge, die soundso alt sind, werden nicht gefunden, Datenbankeinträge, wenn später weitere ergänzt wurden.
Das betrifft aber doch den Inhalt von Dateien, nicht die Datei selbst. "alt" ist sowieso eine nicht ganz zutreffende Wortwahl, aber schön kurz und knapp, richtiger würde man "zuletzt geändert vor" nehmen müssen.
Da stand aber, wenn ich es richtig im Kopf habe, es würde nach allem gesucht. Vielleicht zu spitzfindig von mir, aber wer ändern will ist m.E. in der Begründungspflicht.
Hängt aber davon ab, bei welcher Spalte man den Radiobutton markiert hat, oder?
Nee, hat keinen Einfluss, rot=gelöscht kommt immer zu oberst.
OK, das ist auch eine Logik.
Ich bin leicht farbenblind, und muss immer überlegen ob das Dunkelrot grün ist oder das Hellrot. ☺
Dummes Pech, hab' da Glück gehabt. Ich vermute im Einleitungstext ist die Hervorhebung in korrespondierenden Farben gehalten
Nein, da ist alles weiß unterlegt.
Unterlegt, aber die Schrift ist doch in zwei unterschiedlichen Farben, die beide nicht schwarz sind?
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.
Auch ganz gut, Vielleicht auch: Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch Verzeichnisse Dateien sind - mit speziellem Inhalt, und nach den gleichen Kriterien aufgesucht werden.
Also meine Verzeichnisse haben keine speziellen Inhalte. Außer ~/Bilder/.bademoden/18+ . Im Ernst: Wozu? Was sonst? Und wieso aufgesucht? Um ihnen die Aufwartung zu machen?
Wo wir schon dabei sind:
...
Auch ohne die Klammern ist das einfach gräßlich
Zustimmung!
(Erleichterung! Ein Konsens!)
Vorschlag: Und-Kombination, die Funde müssen alle Kriterien erfüllen: find -mindepth 3 -maxdepth 5 sucht in Unterverzeichnissen der Tiefe 2 - 4.
Find sagt Tiefe 3 bis 5 - Du schlägst als Zählweise 2 - 4 vor. Wieso? Wegen Unter-? Dann lassen wir das Unter weg!
Weiteres Beispiel der UND-Kombination: find -mindepth 3 -type f -name "*.avi" -size +5M sucht ab der Unterverzeichnistiefe 2 UND nur gewöhnliche Dateien UND nur welche mit der Endung .avi UND von mehr als 5 MiB Größe. Oder (ohne direkte Verdeutlichung der UNDs): sucht ab der Unterverzeichnistiefe 3 UND nur gewöhnliche Dateien mit der Endung .avi die größer als 5 MiB sind.
Kompromiss: Weiteres Beispiel der UND-Kombination: find -mindepth 3 -type f -name "*.avi" -size +5M sucht ab der Unterverzeichnistiefe 3 (-mindepth 3 ), und berücksichtigt nur Dateien vom Typ File (-type f ), mit der Endung .avi die mindestens 5 MB groß sind (-size +5M ).
Auf jeden Fall ist ein Parallelzählweise (2-4 statt 3-5) zu vermeiden. Sonst muss man in Zukunft immer nachfragen, welche Zählung jetzt wer verwendet und immer dazuschreiben, welche man selbst verwendet. Wer nicht weiß, was 'Typ File' ist, der weiß, dass er nichts weiß, und das wäre schon viel. Oder er hat es schon mitbekommen. Gewöhnliche Dateien ist dagegen nur pseudoverständlich. Ausführbare Dateien, temporäre Dateien, Logfiles, schreibgeschützte Dateien - was sind gewöhnliche Dateien? Mit der Endung avi, nicht dem Namen - gut beobachtet, gekauft. Pseudosyntax mit UND: Bin ich dagegen. Natürliche Sprache ist oft sehr präzise.
Wie oft hörst oder liest Du Dateitrenner?
In der englischen Form bei der Programmierung sehr oft, sobald es um Dateizugriff geht. In deutsch wird halt "selten" programmiert. Auf deutschen Vorträgen über das Thema kommen Dateitrenner oder Namenstrenner und Pfadtrenner aber auch vor.
Bei Dateitrenner denke ich erst, es geht um das Trennen mehrerer Dateien, nicht darum den Pfad der Datei vom Namen zu trennen.
Mit -path kann man nach Mustern im Pfadnamen zur Datei suchen, nicht nur nach dem Dateinamen selbst.
Tja was soll ich sagen, Du bist der Dienstältere ... aber zumindest mittels verwenden bitte.
Haha, Geschenke immer rasch abgreifen, bevor es sich der andere anders überlegt! Also machen wir's so, und mit mittels oder von mir aus auch mittels mittels. Daran soll es nicht scheitern. ☺
Will man nach Häufigkeit vorgehen, dann müsste wohl size auch vor user.
Genau an der Stelle habe ich auch überlegt. Persönlich verwende ich öfters -user aber nie -size , da Ausgabe, dass alle Verzeichnisse identisch 4096 Byte groß sind, nicht so wirklich spannend ist.
Man sucht ja nicht nur nach Verzeichnissen. Ich zumindest nicht. ☺
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
Benno-007 schrieb: OT: Wegen der Farbblindheit hier im diff könnte man mal das Firefox-Add-on Greasemonkey ausprobieren - vielleicht gibt es da oder allgemein für Firefox schon fertige Add-ons für "Farbenblinde", welche dann z.B. Rot als Blau und Grün als Gelb anzeigen können oder so - wie man es eben will - und siehe da:
Leider ist der Server nur gerade nicht erreichbar.
Danke. Ich hatte mal Greasemonkey installiert, um auf manchen Seiten mit dunkelgrauer Schrift auf hellgrauem Grund Schwarz auf Weiß zu erzwingen. Entweder es war wartungsanfällig oder speicherintensiv oder absturzfreudig - aus einem der Gründen habe ich es wieder verbannt. Aber vielleicht freut es ja jemanden, der nur mitliest oder über das Suchwort Farbenblind hier hinfindet. ☺
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
UlfZibis schrieb: @ user_unknown Habe gerade noch einen neuen "Schuss" gemacht, bitte angucken. Gruß Ulf
| touch leer
find -amin 1
./leer
|
Das a in amin steht für access, nicht für Lesen. Schreiben ist auch ohne Lesen möglich und ist auch access. War vorher schon falsch? Tja - das nennt man Pech. ☺ Ist: Standard: UND-Kombination; die Funde müssen alle Kriterien erfüllen
Soll: Standard: Und-Kombination; die Funde müssen alle Kriterien erfüllen
Das ist kein UNO-Generalsekretär, sondern es geht um das Wort Und, welches hier als Substantivkombination mit Bindestrich geschrieben werden kann, und dabei, als erster Teil der Kombination, mit großem Anfangsbuchstaben geschrieben wird (die Sowohl-als-auch-Politik, der Als-ob-Torschütze). Im Artikel ist schon genug hervorgehoben, Code, Überschriften, Links, fett, kursiv, ... - ab einer gewissen Sättigung verliert es an Wirkung. Es sollte mal jmd. ein Skript schreiben, das den Artikel mit den meisten unterschiedlichen Hervorhebungen im Satz sucht. ☺
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
user_unknown schrieb: frostschutz schrieb: find * sollte man trotzdem niemals machen. Sonst erstellt irgendein Scherzkeks noch eine Datei namens "-delete" und find * löscht dir auf einmal alles weg.
Wer Scherzkeksen auf seinem System das Anlegen von -delete-Dateien ermöglicht, der hat bereits etwas falsch gemacht.
Wie verhinderst du es? 😉
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
Benno-007 schrieb: Wer Scherzkeksen auf seinem System das Anlegen von -delete-Dateien ermöglicht, der hat bereits etwas falsch gemacht.
Wie verhinderst du es? 😉
Der einzige Scherzkeks auf meinem System bin ich. ☺ Da ich mir nicht selbst die Möglichkeit nehmen kann, solche Tretminen anzulegen, muss ich es aus Disziplin oder Angst vor Datenverlust vermeiden, die Gelegenheit auszunutzen. Aber sonst erhält kein Scherzkeks die Möglichkeit.
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Ich hab jetzt mal noch schnell die Datei wieder aus dem Testordner entfernt, denn auch dort ist sie eine tickende Zeitbombe, fiel mir grad erst mal so auf, als ich sie nochmal sah. 😉 rm hat via Tab (bash-completion) auch schon gleich die richtigen Optionen zum Entfernen vorgeschlagen (–).
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3022
Wohnort: Köln
|
Hallo Ihr Lieben, ich muss jetzt mal ein paar Tage kürzer treten, hatte andere Dinge vernachlässigt, die jetzt drängen. Bis die Tage.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3022
Wohnort: Köln
|
Benno-007 schrieb: Wie verhinderst du es? 😉
Kam das nicht von dir, das mit den Detaildiskussionen ... 😈
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Im Artikel. Und das ist ja keine seitenweise Detaildiskussion, sondern nur ein Aspekt - Sicherheitsaspekt - von euch. 😉 Auch wenn er nicht in den Artikel kommt (?!), ist dafür manchmal Platz für ein Posting dazu - in der Tat aber in einer Artikeldiskussion (besonders) grenzwertig.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3022
Wohnort: Köln
|
Hallo zusammen, in Anbetracht des schönen und seltenen Wetters 🐸 , welches ich nutzen möchte, bitte ich um Verlängerung der Bearbeitungsfrist.
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28953
Wohnort: WW
|
Hallo, wie ich weiter oben schon schrieb: Das Fertigstellungsdatum bitte bei Bedarf anpassen.
Kannst du also selber auf ein Datum anpassen, was du für realistisch hältst. Also so 1-3 Wochen mehr ist kein Ding. Gruß, noisefloor
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3022
Wohnort: Köln
|
So ... die Somerhitze verabschiedet sich nun ☹ user_unknown schrieb: UlfZibis schrieb: 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?
Nein. ☺
Hm, tja, schwierig das prägnant und gleichzeitig präzise korrekt auszudrücken 😮 Jedes Verzeichnis enthält mindestens die zwei Spezialverweise . und .. für das aktuelle und das übergeordnete Verzeichnis. Der Punkt ist also auch im Verzeichnis.
Nach Deiner Logik müsste dann aber auch im .. -Pfad gesucht werden, was aber nicht der Fall ist.
Soll'n wir nicht besser doch bei der "Normal-Nutzer"-Interpretation bleiben? Ich hab' mal einen Versuchsballon losgelassen, da können wir natürlich noch dran schleifen. Ansonsten bleibt die Überlegung, ob man den "Trick" mit dem Asterix hinzufügen sollten, evtl. mit Hinweis auf seine Missbrauchsmöglichkeit?
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
UlfZibis schrieb: So ... die Somerhitze verabschiedet sich nun ☹
In Köln, vielleicht! ☺
user_unknown schrieb: UlfZibis schrieb: 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).
Naja, es ist schwierig. Was ist das eigentlich, ein Verzeichnis? Ich denke die meisten verbinden es mit einer räumlichen Vorstellung, nicht mit einer zeitlichen. Ab Montag suche ich meinen Vater. Ansonsten suche ich meine Mutter im Kosovo, nicht? Mit dem Asterix ist es so, dass dieser von der Shell ausgewertet wird, nicht von find. Dass die Shell beim Asterix keinen Punkt und kein Punkt-Punkt liefert liegt daran, dass versteckte Dateien vom Asterix nicht aufgelöst werden und als versteckt gilt jede Datei, deren Name mit einem Punkt beginnt, was für Punkt und Punkt-Punkt als kuriose Sonderfälle auch gilt. Das ist alles eigentlich ganz logisch. ☺ Wieso sollte man den Asterix überhaupt erwähnen?
find foo sucht ab dem Verzeichnis foo.
Kannst Du dem so folgen?
Nein. ☺
Hm, tja, schwierig das prägnant und gleichzeitig präzise korrekt auszudrücken 😮 Jedes Verzeichnis enthält mindestens die zwei Spezialverweise . und .. für das aktuelle und das übergeordnete Verzeichnis. Der Punkt ist also auch im Verzeichnis.
Nach Deiner Logik müsste dann aber auch im .. -Pfad gesucht werden, was aber nicht der Fall ist.
Soll'n wir nicht besser doch bei der "Normal-Nutzer"-Interpretation bleiben?
Wenn ich in meinem Fotordner 2015 die Untervezeichnisse 01 bis 12 habe, und jemand sagt mir, find suche ab dem Verzeichnis 05, dann könnte ich denken 05-12. Gut - exotisches Beispiel, aber dass . und .. Sonderfälle sind, sollte jeder, der sie überhaupt kennt, wissen, und es lässt sich leicht ahnen, dass eine Suche in .. problematisch wäre, weil alle Suchen dann Gefahr laufen, iterativ ins Wurzelverzeichnis vorzustoßen.
Ich hab' mal einen Versuchsballon losgelassen, da können wir natürlich noch dran schleifen. Ansonsten bleibt die Überlegung, ob man den "Trick" mit dem Asterix hinzufügen sollten, evtl. mit Hinweis auf seine Missbrauchsmöglichkeit?
"Im aktuellen Verzeichnis" ist ja richtig. Wer sich wundert, dass das Verzeichnis selbst mitkommt, und das nicht will, kann auch mit -mindepth 1 arbeiten, dann ist er es auch los. Dass es häufig ein Problem ist glaube ich nicht. Dass es wichtig ist auch nicht. Dass die User, die eine Lösung suchen, auf keine kommen mag sein - dafür haben wir aber das Forum. Die Manpage liefert zu .. nur folgendes in einem anderen Kontext:
| -noleaf
Do not optimize by assuming that directories contain 2 fewer subdirectories than their hard link count. This option is needed when searching
filesystems that do not follow the Unix directory-link convention, such as CD-ROM or MS-DOS filesystems or AFS volume mount points. Each directory
on a normal Unix filesystem has at least 2 hard links: its name and its `.' entry. Additionally, its subdirectories (if any) each have a `..'
entry linked to that directory. When find is examining a directory, after it has statted 2 fewer subdirectories than the directory's link count,
it knows that the rest of the entries in the directory are non-directories (`leaf' files in the directory tree). If only the files' names need to
be examined, there is no need to stat them; this gives a significant increase in search speed.
|
Die anderen Änderungen nicke ich ab. ☺
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3022
Wohnort: Köln
|
Du scheinst also auch zu den gelegentlichen/regelmäßigen Nachtaktiven zu gehören. Bei "8:00 Uhr" dachte ich bisher immer ... Frühaufsteher 😀 user_unknown schrieb: UlfZibis schrieb: So ... die Somerhitze verabschiedet sich nun ☹
In Köln, vielleicht! ☺
Ihr in Berlin kriegt auch noch die Abkühlung 😈
Naja, es ist schwierig. Was ist das eigentlich, ein Verzeichnis? Ich denke die meisten verbinden es mit einer räumlichen Vorstellung, nicht mit einer zeitlichen. Ab Montag suche ich meinen Vater. Ansonsten suche ich meine Mutter im Kosovo, nicht?
In der Logik von find entspräche das dann -mindepth 1 -maxdepth 1 -prune . Ohne -mindepth 1 könnte auch Kosovo selbst als Mutter angesehen werden, und ohne -prune würden alle Mütter im Kosovo gefunden werden. Ab lässt sich aber auch hier räumlich verwenden: "Fahre nach Süden und suche Deine Mutter ab dem Kosovo".
Mit dem Asterix ist es so, dass dieser von der Shell ausgewertet wird, nicht von find. Dass die Shell beim Asterix keinen Punkt und kein Punkt-Punkt liefert liegt daran, dass versteckte Dateien vom Asterix nicht aufgelöst werden und als versteckt gilt jede Datei, deren Name mit einem Punkt beginnt, was für Punkt und Punkt-Punkt als kuriose Sonderfälle auch gilt.
Ist schon klar, doch vom Benutzer kann man ja nicht die Kenntnis der inneren Logik der Implementierung abverlangen. Wieso sollte man den Asterix überhaupt erwähnen?
Als Ausweg aus der m.E. überraschenden Standard-Funktionalität. Beispiel:
find -exec chown otto {} \; Der unbedarfte Benutzer wird da nicht auf den Gedanken kommen, dass danach auch der aktuelle Ordner nun otto gehört wenn da steht: "sucht im Verzeichnis ...".
Nach Deiner Logik müsste dann aber auch im .. -Pfad gesucht werden, was aber nicht der Fall ist.
Soll'n wir nicht besser doch bei der "Normal-Nutzer"-Interpretation bleiben?
Wenn ich in meinem Fotordner 2015 die Untervezeichnisse 01 bis 12 habe, und jemand sagt mir, find suche ab dem Verzeichnis 05, dann könnte ich denken 05-12. Gut - exotisches Beispiel,
Zugegeben: Diese Logik hat auch ihren Charme. aber dass . und .. Sonderfälle sind, sollte jeder, der sie überhaupt kennt,
Aber wenn er sie kennt, wie soll er drauf kommen, dass nur einer der beiden von find eingeschlossen wird?
"Im aktuellen Verzeichnis" ist ja richtig. Wer sich wundert, dass das Verzeichnis selbst mitkommt, und das nicht will, kann auch mit -mindepth 1 arbeiten, dann ist er es auch los. Dass es häufig ein Problem ist glaube ich nicht. Dass es wichtig ist auch nicht. Dass die User, die eine Lösung suchen, auf keine kommen mag sein - dafür haben wir aber das Forum.
In meinem Fall habe ich rumprobiert, statt im Forum zu fragen. Weil letztere Vorgehensweise immer mit Wartezeit verbunden ist, bin ich bestimmt nicht der einzige, der das so macht, tja und in diesem Fall übersieht man dann leicht die – zwar utopischen – Nebenwirkungen von find * . Genau deshalb dachte ich, den "Hack" gleich im Artikel zu erwähnen ... mit dem Sicherheitshinweis.
Dass wir unterschiedlicher Meinung sind über den Bedarf nach "Suche ohne ." sind zeigt sich nun daran, dass Du erst jetzt die Dir wohl schon länger bekannte Lösung -mindepth 1 "herausrückst". 👿 Da würde ich doch vorschlagen, dass wir dann die an prominenter Stelle erwähnen, … statt dem Asterix-Hack.
Das scheint ein ganz eigenes Thema zu sein und zeigt wohl, wie alt und deshalb rudimentär find schon ist. Statt dass find selbst sich optimiert um solche Spezialitäten kümmert, muss der Benutzer hier mitdenken.
Die anderen Änderungen nicke ich ab. ☺
Cool 🦆 Neuer Vorschlag: Startverzeichnis(se)
Es wird der Verzeichnisbaum ab den (angegebenen) Startverzeichnissen durchsucht, was mit zusätzlichen Suchkriterien begrenzt werden kann. Auch wenn im folgenden der besseren Lesbarkeit wegen meist "sucht im Verzeichnis" geschrieben steht, ist zu beachten, dass die Startverzeichnisse selbst (alles ist eine Datei) im Regelfall in der Ergebnismenge enthalten sind. sucht im aktuellen Verzeichnis. sucht nur im aktuellen Verzeichnis (das Startverzeichnis selbst – hier . – wird entgegen dem Standard von den Suchergebnissen ausgeschlossen). sucht im Unterverzeichnis foo des aktuellen Verzeichnisses. Usw. ...
Wenn Dir auch hier der Regelfall die Spiegeleier in der Pfanne kräuseln lässt – ein Sonderfall wird ja aufgeführt, können wir es meinetwegen auch weglassen.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
UlfZibis schrieb: Du scheinst also auch zu den gelegentlichen/regelmäßigen Nachtaktiven zu gehören. Bei "8:00 Uhr" dachte ich bisher immer ... Frühaufsteher 😀
Eule mit Weule. ☺ Bevor ich es vergesse, gerade drüber gestolpert: 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 allgemein üblich bei Linux. Das ist der Grund, weshalb -delete ein -depth impliziert: Wenn erst in den Unterverzeichnissen gelöscht wird kann ein dadurch leeres Oberverzeichnis auch gelöscht werden, umgekehrt nicht. Vorschlag: +dadurch -Ober
Naja, es ist schwierig. Was ist das eigentlich, ein Verzeichnis? Ich denke die meisten verbinden es mit einer räumlichen Vorstellung, nicht mit einer zeitlichen. Ab Montag suche ich meinen Vater. Ansonsten suche ich meine Mutter im Kosovo, nicht?
In der Logik von find entspräche das dann -mindepth 1 -maxdepth 1 -prune . Ohne -mindepth 1 könnte auch Kosovo selbst als Mutter angesehen werden, und ohne -prune würden alle Mütter im Kosovo gefunden werden. Ab lässt sich aber auch hier räumlich verwenden: "Fahre nach Süden und suche Deine Mutter ab dem Kosovo".
Ich kann nicht ganz folgen. So weit trägt die räumliche Analogie nicht. Also doch eher Kartons die leer sind, Zeuch enthalten oder weitere Kartons - nur haben wir kein Reservoir an benannten Kartonkaskaden, auf die wir problemlos als Beispiel zugreifen können. Nach Süden ab Kosovo ruft in mir gleich die Vorstellung "und weiter nach Albanien, Griechenland ..." hervor, aber Albanien, Griechenland sind nicht im Kosovo. Andererseits kann eine Mutter im Kosovo schlecht selbst eine Mutter enthalten, die weitere Mütter enthält ...
Mit dem Asterix ist es so, dass dieser von der Shell ausgewertet wird, nicht von find. Dass die Shell beim Asterix keinen Punkt und kein Punkt-Punkt liefert liegt daran, dass versteckte Dateien vom Asterix nicht aufgelöst werden und als versteckt gilt jede Datei, deren Name mit einem Punkt beginnt, was für Punkt und Punkt-Punkt als kuriose Sonderfälle auch gilt.
Ist schon klar, doch vom Benutzer kann man ja nicht die Kenntnis der inneren Logik der Implementierung abverlangen.
Teils schon. Von irgendeinem Mindestvorwissen muss man ausgehen. Darauf aufbauend soll der Artikel ein Mehr an Wissen erzeugen, aber kann kein vollständiges Wissen erzeugen. Er soll v.a. nicht den Eindruck erwecken, dass alles viel leichter sei, als es wirklich ist aber auch nicht abschrecken. Dass der Stern von der Shell ausgewertet wird wissen viele nicht und zwar aus Ignoranz - es wird häufig gesagt aber die Relevanz ist nicht offensichtlich und so geht es hier rein, da raus. Da hilft auch wenig, außer sich die Hände mal am Herd zu verbrennen. Was es mit Punkt und Punkt-Punkt auf sich hat, das wissen wohl noch weniger Leute. Für mich ist es auch nur ein vermientes Gebiet mit Warnschild: Hier könnten Probleme lauern. Ein tiefes Verständnis fehlt mir.
Wieso sollte man den Asterix überhaupt erwähnen?
Als Ausweg aus der m.E. überraschenden Standard-Funktionalität. Beispiel:
find -exec chown otto {} \; Der unbedarfte Benutzer wird da nicht auf den Gedanken kommen, dass danach auch der aktuelle Ordner nun otto gehört wenn da steht: "sucht im Verzeichnis ...".
Ich dachte wir hätten bei den -exec-Varianten eine Warnung, dass man diese vorab mit einem Test prüfen soll. Haben wir aber nicht. Wenn man ein falsches chown auf otto gemacht hat, dann ist es rasch korrigiert. "Finde im Kosovo alle Gebiete, deren Name mit K beginnt" würde vielleicht bei Einigen zur Nachfrage führen, ob der Kosovo selbst auch aufgelistet werden soll, andere würden ihn selbstverständlich aufführen, andere selbstverständlich nicht, oder? Finde ab Kosovo klingt für mich einfach schräg. Statt eine einfache Lösung anzubieten flüchte ich mich in die Eskalation: | find kosovo.txt -size +4M
|
Das sucht natürlich weder in kosovo.txt, noch ab kosovo.txt, ☺ sondern ist nur ein handlicher Test, ob die Datei größer als 4 MiB ist (größer/gleich? RTFM!).
Nach Deiner Logik müsste dann aber auch im .. -Pfad gesucht werden, was aber nicht der Fall ist.
Soll'n wir nicht besser doch bei der "Normal-Nutzer"-Interpretation bleiben?
Wenn ich in meinem Fotordner 2015 die Untervezeichnisse 01 bis 12 habe, und jemand sagt mir, find suche ab dem Verzeichnis 05, dann könnte ich denken 05-12. Gut - exotisches Beispiel,
Zugegeben: Diese Logik hat auch ihren Charme. aber dass . und .. Sonderfälle sind, sollte jeder, der sie überhaupt kennt,
Aber wenn er sie kennt, wie soll er drauf kommen, dass nur einer der beiden von find eingeschlossen wird?
Meist hat man ja mit find weitere Filter am Start. Fluchtversuch in die Autorität: Als jahrelanger Forensupporter (meist informell) kann ich verraten, dass Fragen dazu, ob das aktuelle Verzeichnis mit gefunden wird und wieso im Alltag nicht vorkommen.
"Im aktuellen Verzeichnis" ist ja richtig. Wer sich wundert, dass das Verzeichnis selbst mitkommt, und das nicht will, kann auch mit -mindepth 1 arbeiten, dann ist er es auch los. Dass es häufig ein Problem ist glaube ich nicht. Dass es wichtig ist auch nicht. Dass die User, die eine Lösung suchen, auf keine kommen mag sein - dafür haben wir aber das Forum.
In meinem Fall habe ich rumprobiert, statt im Forum zu fragen. Weil letztere Vorgehensweise immer mit Wartezeit verbunden ist, bin ich bestimmt nicht der einzige, der das so macht, tja und in diesem Fall übersieht man dann leicht die – zwar utopischen – Nebenwirkungen von find * . Genau deshalb dachte ich, den "Hack" gleich im Artikel zu erwähnen ... mit dem Sicherheitshinweis.
Dass wir unterschiedlicher Meinung sind über den Bedarf nach "Suche ohne ." sind zeigt sich nun daran, dass Du erst jetzt die Dir wohl schon länger bekannte Lösung -mindepth 1 "herausrückst". 👿 Da würde ich doch vorschlagen, dass wir dann die an prominenter Stelle erwähnen, … statt dem Asterix-Hack.
Ich habe schon länger das Vorwissen, um auf diese Lösung zu kommen, aber hatte sie bisher nicht, weil ich das Problem nicht hatte. Heikel sind eh nur die Fälle, in denen jmd. -exec oder -delete aufruft, ohne zu testen, und der vorher nie mit anderen Suchen schon bemerkt hat, dass . eine Antwort ist.
|