user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Du willst es doch auch? UlfZibis schrieb: user_unknown schrieb: find ist ein Kommandozeilenprogramm um die Einträge in Dateisystem-Verzeichnissen mittels reichhaltiger Suchkriterien zu durchsuchen. Weiterhin bietet es vielfältige Möglichkeiten die Suchergebnisse weiterzuverarbeiten und/oder formatiert auszugeben.
Die Einträge in Dateisystem-Verzeichnissen finde ich bürokratisch und weniger günstig als das jetzige die Dateisuche.
Klingt es erst mal schön, ja. find ist für mich das Komplement zu grep . grep dient ja auch der Dateisuche, nur eben bezüglich des Inhalts, und find bezüglich des Eintrags im (Was-auch-immer)-Verzeichnis.
Nein. Grep dient der Textsuche. Es sucht Text in Dateien, was sprachlich nicht zwingend zu Textsuche führt, wie man ja auch Waldsuche sagt, wenn man Pilze im Wald sucht - nein, schlechtes Beispiel. Goldsuche - na, passt auch nicht. Find sucht zwar auch in einer Datei, nämlich in / oder einem Untervezeichnis von /, und das Wurzelverzeichnis als Verzeichnis ist natürlich selbst, im Unixsinne, eine Datei - es sucht aber v.a. nach Dateien, nicht in Dateien.
Wer von Dateisystemverzeichniseinträgen liest erwartet sprachlich auch erst mal nichts weiter, als Dateien.
Wo schrieb ich, dass ich im ganzen Artikel von Dateisystemverzeichniseinträgen schreiben wollte? Einmal "bürokratisch" zu Beginn genau bezeichnet, und weiter geht's einfach mit "Einträge".
Der User sucht Dateien, nicht Einträge. Diese figürlichen Begriffe existieren aus einem Grund, nämlich die Vorstellung zu stützen. "Einträge" ist fast vollkommen unspezifisch. Datei fasst ganz gut, was gemeint ist, und ist, selbst in der Windowswelt, weithin bekannt. Auch die manpage spricht ständig von files, nicht von file system entries und später nur noch von entries. Manche man-page wirkt auf den zweiten und dritten Blick als besser durchdacht, als man auf den ersten Blick glauben möchte, spricht man doch Programmierern eher mathematische als sprachliche Kompetenzen zu.
Gewinn ist null, es schreckt nur ab.
Mich schreckte beim Artikel find ab, dass ich durch mühseliges Herumprobieren erst mal herausfinden musste, was es denn tatsächlich tut. Erst dann kann ich es ohne Kopfzerbrechen entspannt nutzen.
Und was hat das mit dem Begriff Einträge zu tun?
Mittels reichhaltiger Suchkriterien bedeutet meines Erachtens, dass die einzelnen Suchkriterien reichhaltig sind, was für einzelne Kriterien bejaht werden könnte, aber wohl nicht gemeint ist. Gemeint ist wohl, dass find ein reichhaltiges Suchkriterienreservoir anbietet. Wieso nicht bei Dabei kann man auf vielfältige Weise die Suche filtern, ... bleiben?
OK, gekauft, kann man besser formulieren.
Dies entspricht doch der tatsächlichen Funktion, und beinhaltet "nebenbei" die Information, dass man damit auch nach Dateien suchen kann. Weitergehen könnte es dann so: Da unter unixoiden Systemen der Leitsatz "Alles ist eine Datei" gilt, werden auch Einträge zu weiteren Verzeichnissen, Sockets usw. gefunden. Der Verzeichnisbaum wird so jeweils ab ggf. explizit bezeichneten Startpunkten durchsucht. Eine Alternative zu find (mit Vor- und Nachteilen) bietet der Befehl locate.
Mein Vorschlag: Da unter unixoiden Systemen der Leitsatz "Alles ist eine Datei" gilt, werden auch Verzeichnisse und anderes, das unter Linux als Datei gespeichert wird (z.B. Sockets), gefunden.
Oder: Da unter unixoiden Systemen der Leitsatz "Alles ist eine Datei" gilt, werden auch Verzeichnisse und anderes, was unter GNU/Linux im Dateiverzeichnis gespeichert wird (z.B. Sockets), gefunden.
Oder eben: Da unter unixoiden Systemen der Leitsatz "Alles ist eine Datei" gilt, werden auch Einträge zu Verzeichnissen und anderem, was unter GNU/Linux im Dateiverzeichnis gespeichert wird (z.B. Sockets), gefunden.
Wir können auch jedesmal GNU-find schreiben, weil es ja doch verschieden ist, vom BSD-find, wie ich vom Hörensagen zu wissen meine. Auch frage ich mich, ob Du oder ein zufälliger Wikileser einen Satz wie "Ich suchte den Alexanderplatz auf dem Stadtplan, denn westlich davon soll das Marx-Engels-Forum liegen" spontan verstehen würdet, oder ob Euch die Erfassung des Sinns leichter gelänge, wenn ich schrieb: "Ich suchte den Alexanderplatzeintrag auf dem Stadtplan, denn westlich davon soll das Marx-Engels-Forum liegen"?
Würde "Ich suchte den Alexanderplatzeintrag auf dem Falk-Stadtplan auf, denn westlich davon soll das Marx-Engels-Forum liegen" die Lage verbessern? Oder wie verhält es sich mit Erdbeeren? Zweifellos ist "Erdbeeren" nur ein Wort. Im eigentlichen Sinne kann man nicht auf den Markt gehen und Erdbeeren kaufen, sondern nur das von dem Wort Erdbeeren Bezeichnete.
Statt:
Es wird der Verzeichnisbaum ab den ggf. explizit bezeichneten Startpunkten durchsucht.
Es wird der ganze Verzeichnisbaum ab explizit genannten Startpunkten oder implizit dem aktuellen Verzeichnis durchsucht.
Geht auch. Ich wollte mich knapp fassen und das mit dem impliziten aktuellen Verzeichnis dem entsprechenden Abschnitt über Startpunkte überlassen. Das mit dem "so jeweils" kann man tatsächlich weglassen.
Geht eigentlich nicht. Entweder der ganze Verzeichnisbaum, oder ab dem explizit genannten Startpunkt. Wenn der Startpunkt nicht das Wurzelverzeichnis ist, dann ist es nicht der ganze Verzeichnisbaum.
Also:
Es wird der ganze Verzeichniszweig vom explizit genannten Startpunkt an oder implizit ab dem aktuellen Verzeichnis durchsucht. Es können auch mehrere Startpunkte benannt werden, die dann alle durchsucht werden. Dass Startpunkte auch einzelne Dateien sein könnten, für die der letzte Teilsatz dann nicht mehr passt, fällt sicher niemandem auf, so dass auch niemand darüber stolpert. Jeder Versuch hier vollkommen präzise zu sein führt m.E. nur zur Verwirrung, so dass ich diese kleine Unsauberkeit in Kauf nehmen möchte, und gerne allein die Verantwortung dafür übernehme.
Der Hauptgrund für den Satz ist, darauf aufmerksam zu machen, dass alle Unterverzeichnisse, soweit nicht explizit ausgeschlossen, mit durchsucht werden. Allerdings verdoppelt man hier auch, was weiter unten unter Startpunkte nochmal gesagt wird. Startpunkte könnte man daher mit der Abschnittsüberschrift verknüpfen, oder?
Wenn man es da schon einbringt, klar
Unten steht dann, u.A.:
Dort beginnt find mit der Suche. Wenn nicht extra angegeben, wird . impliziert. Startpunkt(e) müssen nach evtln. Optionen und vor den ebenfalls optionalen Suchkriterien und Aktionen platziert werden.
Hier stolpere ich regelmäßig über den Satzbau wegen des Punktes. Irgendwann merkt man dann, dass es doch stimmt. Das ließe sich vermeiden:
Dort beginnt find mit der Suche. Wenn keine angegeben sind wird das aktuelle Verzeichnis verwendet. Startpunkt(e) müssen vor den optionalen Suchkriterien und Aktionen platziert werden.
Gekauft, evtl. könnte man auch "das aktuelle Verzeichnis . " schreiben.
Dann hat man den Stolperer ja wieder drin. Die Idee war es, ihn zu beseitigen.
Ansonsten fände ich es durchaus sinnvoll den Leser darauf hinzuweisen, dass es bei find tätsächlich auch Optionen gibt. Zur Erklärung habe ich ja schon "(in diesen Artikel nicht beschrieben)" ergänzt. Man könnte auch "(siehe man-Page)" schreiben. Sonst kommt man nämlich wegen der ähnlichen Syntax leicht auf den Irrtum, die Suchkriterien als Optionen zu sehen.
Ja, für "(in diesen Artikel nicht beschrieben)".
Unterstriche suggerieren Links, da wäre ich für Fettung, weil Fett normalerweise wichtig heißt, und das hier der Punkt der Hervorhebung ist, will aber die eingeschliffenen Wikikonventionen nicht zur Disposition stellen.
Deshalb habe ich Unterstreichungen auch nur sparsam verwendet; wollte nicht immer "so dick auftragen". Andererseits steht fett für Dateinamen etc. Von mir aus kann ich die Unterstreichung aber auch gerne durch Fettung ersetzen. Was würde denn noisefloor dazu meinen?
Es kann doch nicht schaden, wenn man so nebenbei auch erfährt, dass nicht alles, was wie eine Datei aussieht, tatsächlich auch eine im eigentlichen Sinne ist.
Man soll doch umgekehrt rausfinden, dass auch was nicht wie eine Datei aussieht, eine sein kann.
Öhm, was sieht denn nicht wie eine Datei aus, und ist dennoch eine?
Ein Verzeichnis, ein Socket.
So könnte man dann auch im folgenden Artikel – soweit passend – den Begriff "Einträge" konsequent weiterverwenden und der Anspruch "Das Wiki muss immer versuchen wahr zu bleiben, auch in der Vereinfachung, sonst ist es wertlos." wäre voll erfüllt.
Nachdem man erklärt hat, dass alles eine Datei ist, kann man Datei benutzen - die manpage von find spricht auch dauernd von files. Eine Handvoll Einträge namens Entry bezeichnet anderes.
Tja, das ist hier die Gretchenfrage. Ein Kompromiss wäre vielleicht "Dateinamen".
Nein. Was soll das bringen? Meist wird der User den suchen, weil er die Datei identifiert und zwar wenn man Dateiname so versteht, dass der Pfad zur Datei gesucht wird. Im Defaultfall liefert find aber den relativen Pfad zur Datei - das ist einer von überabzählbar vielen möglichen Pfadnamen für die Datei. Willst Du wirklich "einen relativen Pfadnamen" benutzen?
Wenn nicht die ganzen ggf. dort darunter liegenden Verzeichnisbäume durchsucht werden sollen, können diese beidseitig mit zusätzlichen Suchkriterien begrenzt werden.
Ich verstehe was mit beidseitig begrenzt gemeint ist, aber ob es der unbefangene Leser versteht, der es noch nicht weiß, bezweifle ich.
Muss ich noch mal drüber grübeln, wie man das besser formulieren könnte.
"können diese mit zusätzlichen Suchkriterien nach Mindest- und Maximaltiefe begrenzt werden." wäre eine Option, aber das kommt doch ohnehin beim -*depth-Parameter.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Nix da. ☺ Man sucht den Arzt auf. Wenn man eine Datei öffnen will, dann sagt man dem Editor, dass er die Datei öffnen soll, und das Dateisystem liefert einem die Datei aus.
Ich würde sagen, das OS liefert sie, und dafür muss es sie aufsuchen, damit der Editor oder sonst wer darin Daten finden kann. Ich suche eine Lichtung im Wald auf, um dort Kräuter zu suchen und zu finden. Aber bei find gehen wir ja gar nicht so weit, wir suchen nur den Fleck auf einer Karte auf, der uns die Eigenschaften der Lichtung beschreibt.
Dem widerspreche ich wieder spitzfindig, dass es ohne OS überhaupt kein Dateisystem gibt.
Wo habe ich das behauptet, dass ein Dateisystem einem OS bedarf? (Spitzfindig: Ein Pappkarten-Dateisystem braucht auch kein OS.) Aber ich gebe Dir Recht: Ein Dateisystem muss sogar schon existieren, bevor man einem OS den Code hinzufügen kann, um damit umgehen zu können, wie auch das Postleitzahlen-System schon existieren muss, bevor man Verteilanlagen danach programmieren kann. Also mit Dateisystem meine ich die Art, wie Date(i)n auf einem Datenträger angeordnet werden, nicht die "Maschine", die darauf programmiert ist, den Datenträger entsprechend lesen und beschreiben zu können.
Das Dateisystem ist integraler Bestandteil des OS, deswegen kann das OS nicht die Dateien aufsuchen, so wie Du auch nicht Deinen Magen aufsuchen kannst.
Die Dateien befinden sich aber doch nicht im OS, sondern auf einem Datenträger. Es gibt auch Betriebssysteme, die nix von Dateisystemen wissen, hab' selbst mal ein solches programmiert, für einen 4-Bit-Prozessor in einem digitalen Telefon, der brauchte nur 5 mW bei 6 MHz. Interessant: Ein moderner Prozessor mit 8 x 4 Bit und 500 x 6 MHz braucht ziemlich genau 8 x 500 x 5 mW. Wo blieb da der Fortschritt?
Wenn ich mit -path und -size suche, dann interessiert mich nicht, wie das Dateisystem organisiert ist, ob die Informationen in einer Liste vorgehalten werden oder ob das Programm die Datei selbst untersucht.
Wie soll man denn die pfadbezeichnungsnamengestützte Methode zum aufsuchen der Datei überhaupt nutzen können, wenn einen nicht interessiert wie das Dateisystem organisiert ist, nämlich in Pfadbäumen. Wäre das Dateisystem z.B. nach Dateigrößen oder nach Typ des Inhalts organisiert, käme man mit einer Pfadbezeichnung nicht weit.
Die Liste könnte alphabetisch organisiert sein.
Genau, oder nach Sternzeichen, jedem XY-System seine eigene Ordnung.
Außerdem hat Deine Vorliebe für Wortungetüme jetzt dazu geführt, dass Du mit pfadbezeichnungsnamengestützte Methode eine überflüssige Verdopplung produziert hast, denn was, wenn nicht ein Name, ist eine Bezeichnung?
Meine Telefonnummer z.B. ist eine, die kein Name ist. Die Methode, nach gefundenem Dateieintrag die Datei aufzusuchen stützt sich auch nicht auf Namen, sondern auf digitale Sektoradressen. Aber gut, pfadbezeichnungsgestützt hätte auch gereicht, hab' wohl beim Editieren das Radieren vergessen.
Der User sucht aber i.d.R. nicht, oder nur mittelbar, die Bezeichnung. Er sucht das Bezeichnete, sprich, die Datei.
find tut das aber nicht. Deshalb braucht's einen 2. Befehl, z.B. cat mein/Pfad/Dateiname , dabei ist "mein/Pfad/" die Pfadbezeichnung (von find gefunden), ob das ein Name ist kann man diskutieren ... oh nein, lieber nicht.
Denn nicht die Bezeichnung hat eine -size +10M, sondern die Datei. Nicht die Bezeichnung ist soundsoalt,
Wollte ich auch nicht behauptet haben. Größe, Name, Besitzer etc. der Datei werden von find gleichermaßen im Dateiverzeichniseintrag gefunden.
Man kann auch im Kölner Rathaus Meldeeinträge von Frauen nach den gleichen Kriterien wie Name, Größe und Alter suchen ... also ist die Erklärung "mit gleichen Kriterien suchen" nicht spezifisch für unseren Spruch, sondern passt dann eher für einen ganz anderen: "Alles ist eine Person".
Ich verstehe diesen Einwand nicht. Dass der User im Dateisystem etwas sucht und nicht im Rathaus, und dass es Dateien, nicht Frauen sind, war bislang, dachte ich, unstrittig.
Du schriebst irgenwo mal sinngemäß sowas wie "... alles ist eine Datei, und kann deshalb mit gleichen Kriterien gesucht werden." Dem wollte ich entgegen halten, dass man mit den gleichen Kriterien auch nach etwas suchen kann, was nicht eine Datei ist. Aber die Eintrags-Aufsuch-Methode (hier Systemaufruf mittels Posix-Pfadbezeichnung ./. da Karteikartenblättern mittels Straße und Hausnummer (oder vielleicht auch Name und Vorname)) wird von dem (Datei-)System des jeweiligen Verzeichnisses bestimmt. Bei letzterem könnte man auch analog sagen, "Alles ist eine juristische Person", Menschen wie Firmen, alle haben eine postalische Adresse.
Nach Deiner Nomenklatur haben Personen nicht Adressen, sondern Adressverzeichniseinträge.
Nicht ganz, die Adressen (eine Bezeichnung aus Straßenname, Hausnummer und Ortsbezeichnung) existieren auch ohne Eintrag in einem Verzeichnis, genauso wie Dateien, die von Datenträgern gehabt werden. Und nicht alle Personen haben Adressen, wie z.B. in der 3-Mio-Metropole Bamako. Die sind da genauso umständlich aufzusuchen, wie Dateien, wenn das Verzeichnis futsch ist.
Wer's nicht rafft bekommt einen Eintrag ins Klassenbuch.
Gute Idee!
Kriterien sind das, was der User find übergibt, wärend die Art, wie find damit dann arbeitet, die Methode ist.
Von der Methode spreche ich hier aber nicht, sondern von der, wie die Daten angesichts eines hierarchischen Dateisystems mittels Pfadbezeichnern gesucht, gefunden und genutzt (=aufgesucht, wie beim Arzt) werden.
Wir reden hier nicht davon, wie das Programm mit dem Betriebs- und Dateisystem arbeitet, sondern wie der Benutzer mit dem Programm find arbeitet.
Und dafür muss der Benutzer das (Pfad-)Bezeichnungs-System als Teil des Dateisystems kennen. Und um die Datei verwenden zu können, muss er sie nicht nur suchen, sondern auch finden, und das verstehe ich unter aufsuchen, wobei find erst mal nur den/die Pfad- und Dateinamen/bezeichnung findet.
Langer Rede kurzer Sinn:
Ein Dateiverzeichnis enthält als Einträge Dateien.
... enthält also doch Einträge 😉 (von Namen und Eigenschaften) von Dateien und nicht nur das, sondern auch von Verzeichnissen, Sockets etc. Würde das Verzeichnis nicht Dateien, sondern Pilze enthalten, wäre es kein Dateiverzeichnis sondern ein Pilzverzeichnis.
Auch ein Pilzverzeichnis enthält keine Pilze, sondern deren Namen und Eigenschaften, es beschreibt sie also nur. Und ein Straßenverzeichnis auf einem Stadtplan enthält nicht nur Namen von Straßen, sondern auch von Plätzen und deren Koordinaten und evtl. auch von Sehenswürdigkeiten.
Korrekt müsste man also nicht von einem Dateiverzeichnis, sondern von einem Dateibezeichnerverzeichnis reden.
Reicht nicht, sondern Dateibezeichner- und -eigenschaftenverzeichnis.
Jetzt nennt der arglose und schlecht informierte User aber /etc, /root, /home/stefan und /tmp Verzeichnis, so als wären das alles unterschiedliche Verzeichnisse, dabei sind sie doch alle im gleichen Verzeichnis verzeichnet. Siehst Du, wohin dieser Versuch, zwischen Signifikant und Signifikat zu unterscheiden uns führen wird? Ich sage es Dir: In die Klappsmühle!
Das ist eben die Krux mit einem hierarchischen Verzeichnis, wie wir es von Linux kennen, und deshalb u.a. ist find ja so kompliziert. Die erste DOS-Version war da einfacher, sie kannte nur ein Wurzelverzeichnis. Und auch ein Telefonanschlussverzeichnis ist da vergleichsweise einfach. Das Landesverzeichnis enthält nur Stadtverzeichnisbezeichnungen und ein Stadtverzeichnis nur Telefonanschussbezeichnungen (Namen und Telefonnummern), und man könnte auch noch ein Weltverzeichnis überordnen. Da wir nun eine Möglichkeit gefunden haben, den unixoiden Spruch ohne "suchen" bzw. "aufsuchen" zu erläutern, können wir nun aufatmen.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Nachtrag: find ... + klappt sehr wohl mit md5sum:
| t201:~/lib/dicts > find -name "*sh" -execdir md5sum {} +
fa9c16eeceec2264c332f825cffe4b76 ./gleicheWortlaenge.sh
af2d89f7d166abd6364bf22471bc71e0 ./wortwieletztes.sh
954ff8f0faee0bc57f3bea7967993c86 ./wortlaengenanzahl.sh
71f4b7b550876207ae7f7b92d7413572 ./zufallsworte.sh
t201:~/lib/dicts > md5sum *.sh
fa9c16eeceec2264c332f825cffe4b76 gleicheWortlaenge.sh
954ff8f0faee0bc57f3bea7967993c86 wortlaengenanzahl.sh
af2d89f7d166abd6364bf22471bc71e0 wortwieletztes.sh
71f4b7b550876207ae7f7b92d7413572 zufallsworte.sh
|
(alt) * Ohne weitere Angaben gibt find die Namen der gefundenen Dateien aus: (neu) * Ohne weitere Angaben gibt `find` nur die gefundenen Dateinamen inkl. relativem Pfad aus: {{{#!vorlage Befehl
find /boot/grub/ -name "he*"
/boot/grub/hexdump.mod
/boot/grub/hello.mod
Das "nur" würde ich weglassen, statt "inkl. relativem Pfad" würde ich, wenn überhaupt, "mit relativem Pfad" schreiben, und wenn, dann würde ich ein Beispiel wählen, das auch einen relativen Pfad zeigt.
Startpunkt(e)
Dort beginnt find mit der Suche – im aktuellen Verzeichnis, wenn keine extra angegeben sind.
Wieso extra? Wenn keine angegeben sind. Vorschlag: Wenn keine Startpunkte angegeben sind beginnt find mit der Suche im aktuellen Verzeichnis.
Deine Änderungsanmerkung:
Verkomplizierung und Verwirrung durch "test" entfernt; "test" könnte so missverstanden werden, dass es dabei um das Testen eines Befehls in einem Testordner geht.
(war) find test/ -depth -name "c*"
(ist) find -depth -name "c*"
Geht es ja auch. Alt: | find test/ -name "c*" -delete
|
Löscht im Verzeichnis test und dessen Unterverzeichnissen alle Dateien, die mit 'c' beginnen.
Neu:
Löscht 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 z.B. mit rm .
Das löscht nicht alle Dateien, die mit c beginnen, sondern nur im aktuellen Verzeichnis und dessen Unterverzeichnissen. Und rm löscht allgemein nicht Verzeichnisse. Bei den Beispielen und Sätzen habe ich mir was gedacht und sie in der Regel auch überprüft. Dass sie sich einfach weglesen heißt nicht, dass sie nur so dahingeplaudert sind. Hier war auch nebenbei ein Startverzeichnis gezeigt.
(war) * die Kombination mit -print
(ist) * Ausgabe erzwingen mit -print
Ohne Kombination mit anderen Befehlen muss man keine Ausgabe erzwingen, weil das der Defaultfall ist. Auch hier steht "Kombination" aus einem Grund.
* Meist empfiehlt sich -execdir statt -exec 325 find test -type d -execdir tar -cjf archiv.bz2 {} \;
325 find -type d -execdir tar -cjf archiv.bz2 {} \;
326 326 -execdir führt das Kommando aus dem Verzeichnis heraus aus, in dem die Datei gefunden wird. So wird also für jedes Verzeichnis ein archiv.bz2 vor O* Meist empfiehlt sich -execdir statt -exec 325 find test -type d -execdir tar -cjf archiv.bz2 {} \;
325 find -type d -execdir tar -cjf archiv.bz2 {} \;
326 326 -execdir führt das Kommando aus dem Verzeichnis heraus aus, in dem die Datei gefunden wird. So wird also für jedes Verzeichnis ein archiv.bz2 vor Ort angelegt.rt angelegt.
Das Startverzeichnis test drängt dem Leser die Tatsache auf, dass Dateien eben nicht im aktuellen Verzeichnis gefunden werden, und es so einen Unterschied macht. Wieso hast Du das wieder weggemacht?
70 sucht Dateien die n Zuordnungseinheiten belegen. Folgende Marker 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.
70 sucht Dateien die n Zuordnungseinheiten belegen. Folgende Etiketten können
Inwiefern ist Etiketten besser als Marker?
Bezeichnet dieser ein Verzeichnis – z.B. . – zählt dessen Inhalt schon zu Tiefe 1.
Hatten wir schon mal: Ein Punkt im Fließtext liest sich schlecht. "zählt dieses als Tiefe 1". Was soll das mit "dessen Inhalt"? Dessen Inhalt können ja weitere Unterverzeichnisse sein. 123 sucht im aktuellen Verzeichnis, findet also auch . .
121 sucht ab dem aktuellen Verzeichnis, findet also auch . .
... (viele mehr)
Hatten wir das nicht geklärt? Man sucht im Verzeichnis, nicht ab einem Verzeichnis, weil es hierarchisch ist, nicht sequentiell. Untersuch mal ein paar Userbeiträge, wie oft die in einem Verzeichnis oder ab einem Verzeichnis irgendwas tun.
sucht nach den vollständigen Namen hausarbeit.odt.
sucht nach Einträgen mit dem vollständigen Namen hausarbeit.odt
Es bläht die Sätze sinnlos auf.
findet nur Verzeichnisse, aber keine sonstigen "Dateien".
Sinnlose Anführüngsstriche.
sucht von Verzeichnistiefe 3 bis 5.
sucht in Verzeichnistiefe 3 bis 5.
Von-bis ist Dir zu geläufig? Kommt mir vor, als ob Du auf Teufel komm raus soviel ändern willst wie Du nur kannst.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb: user_unknown schrieb: Dem widerspreche ich wieder spitzfindig, dass es ohne OS überhaupt kein Dateisystem gibt.
Wo habe ich das behauptet, dass ein Dateisystem einem OS bedarf? (Spitzfindig: Ein Pappkarten-Dateisystem braucht auch kein OS.)
Dann schreib einen Findartikel für ein Pappkartensystem. Das Betriebssystem (Ubuntu-Gnu-Linux - nicht Dein 4-Bit-Prozessor) mit find hat eine symbolische Abbildung der Dateien, die als Baum organisiert ist. Ich denke find sucht darin nach Dateien - genaugenommen nach den Abbildungen der Dateien, aber da der eindeutige Name der Datei (also mit Pfad) zugleich die Zugriffsmöglichkeit auf die Datei darstellt lässt man diese Betrachtung außen vor. Ohne laufendes Betriebssystem, dass den Bytesalat auf den Datenträgern interpretiert, sind die Dateien zwar auch da, aber nicht nutzbar.
Also mit Dateisystem meine ich die Art, wie Date(i)n auf einem Datenträger angeordnet werden, nicht die "Maschine", die darauf programmiert ist, den Datenträger entsprechend lesen und beschreiben zu können.
Ja, und diese Betrachtungsweise ist eben zu hardwarenah. Die Dateien im Dateisystem sind nämlich teilweise gar nicht auf einem Datenträger angeordnet, oder ist RAM auch ein Datenträger? Und andere Dateien können über mehrere verschiedene Datenträger verteilt sein, wovon das Betriebssystem aber abstrahiert.
Das Dateisystem ist integraler Bestandteil des OS, deswegen kann das OS nicht die Dateien aufsuchen, so wie Du auch nicht Deinen Magen aufsuchen kannst.
Die Dateien befinden sich aber doch nicht im OS, sondern auf einem Datenträger.
Auf mehreren Datenträgern oder einem oder keinem - das interessiert uns nicht. Wir sehen einen Baum mit einer Wurzel und mehreren Ästen und Unterästen bis hin zu Blättern.
Wenn ich mit -path und -size suche, dann interessiert mich nicht, wie das Dateisystem organisiert ist, ob die Informationen in einer Liste vorgehalten werden oder ob das Programm die Datei selbst untersucht.
Wie soll man denn die pfadbezeichnungsnamengestützte Methode zum aufsuchen der Datei überhaupt nutzen können, wenn einen nicht interessiert wie das Dateisystem organisiert ist, nämlich in Pfadbäumen. Wäre das Dateisystem z.B. nach Dateigrößen oder nach Typ des Inhalts organisiert, käme man mit einer Pfadbezeichnung nicht weit.
Die Liste könnte alphabetisch organisiert sein.
Genau, oder nach Sternzeichen, jedem XY-System seine eigene Ordnung.
Der Punkt ist, dass der User oft nicht viel darüber weiß. Er sieht nur die Baumstruktur des OS und weiß i.d.R. wieviele Platten, vielleicht sogar Partionen im System sind und USB-Sticks usw. Und wenn man die zweite oder eine verfeinerte Suche losschickt, dann beantwortet find eine Anfrage auch aus dem Cache, womit schlüssig bewiesen ist, dass die Dateien zwar gesucht, aber nicht zwingend aufgesucht werden, was auch schon dadurch bewiesen war, dass manche Dateien nicht gefunden werden, obwohl sie gesucht wurden - mangels Existenz freilich nicht aufgesucht wurden.
Außerdem hat Deine Vorliebe für Wortungetüme jetzt dazu geführt, dass Du mit pfadbezeichnungsnamengestützte Methode eine überflüssige Verdopplung produziert hast, denn was, wenn nicht ein Name, ist eine Bezeichnung?
Meine Telefonnummer z.B. ist eine, die kein Name ist.
Nein. Eine Telefonnummer ist ein Name.
Die Methode, nach gefundenem Dateieintrag die Datei aufzusuchen stützt sich auch nicht auf Namen, sondern auf digitale Sektoradressen. Aber gut, pfadbezeichnungsgestützt hätte auch gereicht, hab' wohl beim Editieren das Radieren vergessen.
Der User sucht aber i.d.R. nicht, oder nur mittelbar, die Bezeichnung. Er sucht das Bezeichnete, sprich, die Datei.
find tut das aber nicht. Deshalb braucht's einen 2. Befehl, z.B. cat mein/Pfad/Dateiname , dabei ist "mein/Pfad/" die Pfadbezeichnung (von find gefunden), ob das ein Name ist kann man diskutieren ... oh nein, lieber nicht.
Ein Name ist ein Zeichen ist eine Bezeichnung. Der Pfad ist eine Bezeichnung. Das Wort "Datei" ist auch eine Bezeichnung, ist ein Name.
Denn nicht die Bezeichnung hat eine -size +10M, sondern die Datei. Nicht die Bezeichnung ist soundsoalt,
Wollte ich auch nicht behauptet haben. Größe, Name, Besitzer etc. der Datei werden von find gleichermaßen im Dateiverzeichniseintrag gefunden.
Oder auch nicht gefunden. Weil die Datei nicht aufgesucht, sondern gesucht wird. Und wenn sie nicht da ist ist da auch nichts, was man aufgesucht hat, außer die symbolische Auflistung der Dateien. Und wenn man mit cat eine Datei ausgibt, dann liefert das OS die Datei nicht an find, sondern eine Zeichenfolge, die auf die Datei verweist, und find reicht nicht die Datei, sondern ihre Adresse an cat weiter, nehme ich an, und cat gibt sie aus, ohne dass find die Datei aufgesucht hätte.
Man kann auch im Kölner Rathaus Meldeeinträge von Frauen nach den gleichen Kriterien wie Name, Größe und Alter suchen ... also ist die Erklärung "mit gleichen Kriterien suchen" nicht spezifisch für unseren Spruch, sondern passt dann eher für einen ganz anderen: "Alles ist eine Person".
Worauf willst Du hinaus?
Ich verstehe diesen Einwand nicht. Dass der User im Dateisystem etwas sucht und nicht im Rathaus, und dass es Dateien, nicht Frauen sind, war bislang, dachte ich, unstrittig.
Du schriebst irgenwo mal sinngemäß sowas wie "... alles ist eine Datei, und kann deshalb mit gleichen Kriterien gesucht werden." Dem wollte ich entgegen halten, dass man mit den gleichen Kriterien auch nach etwas suchen kann, was nicht eine Datei ist.
Am Artikelanfang, ja. Aber mit find kannst Du nicht nach Frauen suchen, auch wenn die ein Alter haben. Ich habe den Spruch nicht geprägt und würde nicht unterschreiben, dass alles unter Unix eine Datei ist (kurz: Alles ist eine Datei). Der Spruch soll helfen sich zu erinnern, dass (v.a.) auch Verzeichnisse Dateien sind. Mit Suchen/Aufsuchen hat das jetzt was zu tun?
Kriterien sind das, was der User find übergibt, wärend die Art, wie find damit dann arbeitet, die Methode ist.
Von der Methode spreche ich hier aber nicht, sondern von der, wie die Daten angesichts eines hierarchischen Dateisystems mittels Pfadbezeichnern gesucht, gefunden und genutzt (=aufgesucht, wie beim Arzt) werden.
Die werden aber oft nicht benutzt, sondern oft wird nur das, was im Verzeichnis steht, benutzt. Owner, Alter, Name, Größe - das steht doch alles im Verzeichnis, dafür muss die Datei nicht aufgesucht werden. Und wenn was passieren soll, mit -exec und Verwandten, dann wird den betreffenden Programmen auch nur der Name der Datei (mit Pfad) übergeben, und diese entscheiden selbst, ob sie die Datei aufsuchen.
Wir reden hier nicht davon, wie das Programm mit dem Betriebs- und Dateisystem arbeitet, sondern wie der Benutzer mit dem Programm find arbeitet.
Und dafür muss der Benutzer das (Pfad-)Bezeichnungs-System als Teil des Dateisystems kennen. Und um die Datei verwenden zu können, muss er sie nicht nur suchen, sondern auch finden, und das verstehe ich unter aufsuchen, wobei find erst mal nur den/die Pfad- und Dateinamen/bezeichnung findet.
Eben. Findet sucht die Datei nicht auf, sondern sucht nur Informationen über die Datei.
Langer Rede kurzer Sinn:
Ein Dateiverzeichnis enthält als Einträge Dateien.
... enthält also doch Einträge 😉 (von Namen und Eigenschaften) von Dateien und nicht nur das, sondern auch von Verzeichnissen, Sockets etc.
Verzeichnisse und Sockets sind Dateien, fangen wir jetzt wieder bei 0 an?
Würde das Verzeichnis nicht Dateien, sondern Pilze enthalten, wäre es kein Dateiverzeichnis sondern ein Pilzverzeichnis.
Auch ein Pilzverzeichnis enthält keine Pilze, sondern deren Namen und Eigenschaften, es beschreibt sie also nur. Und ein Straßenverzeichnis auf einem Stadtplan enthält nicht nur Namen von Straßen, sondern auch von Plätzen und deren Koordinaten und evtl. auch von Sehenswürdigkeiten.
Eben, und deswegen kannst Du all das im Verzeichnis nicht aufsuchen, sondern nur suchen. Aber im Einwohnerverzeichnis von Köln steht Frau Rosalinder Meierstolz. Genaugenommen ein Eintrag zu dieser Frau, natürlich nicht die Frau selbst. Trotzdem behandelt die Sprache hier oft den Eintrag wie das Ding: "Suchen Sie mir mal Frau Meierstolz raus!" "Hat Frau Meierstolz schon ihren Steuervermerk?" usw.
Die Einwohner sind im Einwohnermelderegister erfasst. Was ist darin erfasst? Die Einwohner. Du würdest sagen die Einwohnermelderegistereinträge, aber es erleichtert nicht die Erfassung.
Und auch ein Telefonanschlussverzeichnis ist da vergleichsweise einfach. Das Landesverzeichnis enthält nur Stadtverzeichnisbezeichnungen und ein Stadtverzeichnis nur Telefonanschussbezeichnungen (Namen und Telefonnummern), und man könnte auch noch ein Weltverzeichnis überordnen.
Als ich mein letztes Telefonbuch hatte enthielt das oft Name und Anschrift und Telefonnummer und teils Berufsbezeichnung und Titel. Trotzdem hieß es schlicht "Telefonbuch". So schlicht wollen wir das auch hier handhaben.
Da wir nun eine Möglichkeit gefunden haben, den unixoiden Spruch ohne "suchen" bzw. "aufsuchen" zu erläutern, können wir nun aufatmen.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Du willst es doch auch?
Was?
find ist ein Kommandozeilenprogramm um die Einträge in Dateisystem-Verzeichnissen mittels reichhaltiger Suchkriterien zu durchsuchen. Weiterhin bietet es vielfältige Möglichkeiten die Suchergebnisse weiterzuverarbeiten und/oder formatiert auszugeben.
Etwas schöner: find ist ein Kommandozeilenprogramm um die Einträge in den Verzeichnissen des Dateisystems mittels vielfältiger Suchkriterien zu durchsuchen. Weiterhin bietet es zahlreiche Möglichkeiten die Suchergebnisse weiterzuverarbeiten und/oder formatiert auszugeben.
find ist für mich das Komplement zu grep . grep dient ja auch der Dateisuche, nur eben bezüglich des Inhalts, und find bezüglich des Eintrags im (Was-auch-immer)-Verzeichnis.
Nein. Grep dient der Textsuche.
Mit grep -r Klaus . suche ich die Dateien, wo Klaus drin vorkommt. Darauf bezieht sich mein Vergleich, denn das ich für mich der übliche Anwendungsfall. Im allerobersten Beispiel von grep heißt es immerhin auch: Findet rekursiv (-r) alle Dateien im ...
Find sucht zwar auch in einer Datei, nämlich in / oder einem Untervezeichnis von /, und das Wurzelverzeichnis als Verzeichnis ist natürlich selbst, im Unixsinne, eine Datei - es sucht aber v.a. nach Dateien, nicht in Dateien.
Genau wie ich schrieb.
Wer von Dateisystemverzeichniseinträgen liest erwartet sprachlich auch erst mal nichts weiter, als Dateien.
Wo schrieb ich, dass ich im ganzen Artikel von Dateisystemverzeichniseinträgen schreiben wollte? Einmal "bürokratisch" zu Beginn genau bezeichnet, und weiter geht's einfach mit "Einträge".
Der User sucht Dateien, nicht Einträge. Diese figürlichen Begriffe existieren aus einem Grund, nämlich die Vorstellung zu stützen. "Einträge" ist fast vollkommen unspezifisch.
"Größe", "Alter" etc. sind aber genauso unspezifisch. Auch hier ist der Leser in der Lage, dies im Kontext mit dem Artikel auf Dateien zu beziehen. Die manpage schreibt im übrigen auch: find searches the directory tree ...
Datei fasst ganz gut, was gemeint ist, und ist, selbst in der Windowswelt, weithin bekannt. Auch die manpage spricht ständig von files, nicht von file system entries und später nur noch von entries.
Die manpage schreibt: ... at which point find moves on to the next file name. ... im directory tree, womit die Einträge im Verzeichniss gemeint sind. Ok, das mit den Einträgen klingt tatsächlich etwas bürokratisch, doch mit "Dateinamen" wäre ich doch ganz gut auf Linie.
Manche man-page wirkt auf den zweiten und dritten Blick als besser durchdacht, als man auf den ersten Blick glauben möchte, spricht man doch Programmierern eher mathematische als sprachliche Kompetenzen zu.
Dem wage ich aus obigen Zitaten heraus nicht zu widersprechen.
Mich schreckte beim Artikel find ab, dass ich durch mühseliges Herumprobieren erst mal herausfinden musste, was es denn tatsächlich tut. Erst dann kann ich es ohne Kopfzerbrechen entspannt nutzen.
Und was hat das mit dem Begriff Einträge zu tun?
Damit weniger, eher mit anderen reichlich beschriebenen Unverständlichkeiten, die Ungenauigkeit, dass nicht Dateien, sondern Dateinamen gefunden werden, kam halt noch oben drauf. Wie klingt denn? : Das Kommandozeilenprogramm find dient der Dateisuche. Dabei kann man ...
Dies widerspricht weder dem, dass eigentlich nur Dateinamen mit Pfad gefunden werden, noch dass man mit find auch Nicht-Dateien gesucht werden können. Wobei ich dieses "Dabei ..." und das mehrfache Wiederholen von "Such.." auch nicht wirklich gelungen finde. Deshalb meine Umformulierung: ... mittels vielfältiger Suchkriterien. Weiterhin bietet es zahlreiche Möglichkeiten die Ergebnisse weiterzuverarbeiten und/oder formatiert auszugeben.
Da unter unixoiden Systemen der Leitsatz "Alles ist eine Datei" gilt, werden auch Verzeichnisse und anderes, was unter GNU/Linux im Dateiverzeichnis gespeichert wird (z.B. Sockets), gefunden.
Oder eben: Da unter unixoiden Systemen der Leitsatz "Alles ist eine Datei" gilt, werden auch Einträge zu Verzeichnissen und anderem, was unter GNU/Linux im Dateiverzeichnis gespeichert wird (z.B. Sockets), gefunden.
Wir können auch jedesmal GNU-find schreiben, weil es ja doch verschieden ist, vom BSD-find, wie ich vom Hörensagen zu wissen meine.
Ich war mir nicht ganz sicher, ob Syntax und System von Pfadbezeichnungen etc. schon vom Linux-Kernel so vorgegeben sind, oder erst durch die GNU-Umgebung, um evtln. Spitzfindigkeiten deinerseits vorzubeugen. Im Artikel muss das nicht wirklich so genau stehen.
Würde "Ich suchte den Alexanderplatzeintrag auf dem Falk-Stadtplan auf, denn westlich davon soll das Marx-Engels-Forum liegen" die Lage verbessern?
Zumindest wird er gut daran tun, die Einträge im Straßenverzeichnis des Stadtplans zu nutzen, und dies tut er, weil er nämlich nicht wirklich den Alexanderplatzeintrag auf dem Falk-Stadtplan sucht, sondern den Alexanderplatz in Berlin. Wie bei find , der Stadtplan dient der Straßen- und Platzsuche, findet/liefert aber nur "Pfad"-Beschreibungen.
Geht eigentlich nicht. Entweder der ganze Verzeichnisbaum, oder ab dem explizit genannten Startpunkt. Wenn der Startpunkt nicht das Wurzelverzeichnis ist, dann ist es nicht der ganze Verzeichnisbaum.
Also:
Es wird der ganze Verzeichniszweig vom explizit genannten Startpunkt an oder implizit ab dem aktuellen Verzeichnis durchsucht. Es können auch mehrere Startpunkte benannt werden, die dann alle durchsucht werden.
Hab' ich schon eingearbeitet.
Dass Startpunkte auch einzelne Dateien sein könnten, für die der letzte Teilsatz dann nicht mehr passt, fällt sicher niemandem auf, so dass auch niemand darüber stolpert. Jeder Versuch hier vollkommen präzise zu sein führt m.E. nur zur Verwirrung, so dass ich diese kleine Unsauberkeit in Kauf nehmen möchte, und gerne allein die Verantwortung dafür übernehme.
Sollte jetzt auch schon elegant eingearbeitet sein.
Dann hat man den Stolperer ja wieder drin. Die Idee war es, ihn zu beseitigen.
Gekauft.
Man soll doch umgekehrt rausfinden, dass auch was nicht wie eine Datei aussieht, eine sein kann.
Öhm, was sieht denn nicht wie eine Datei aus, und ist dennoch eine?
Ein Verzeichnis, ein Socket.
Unter Datei verstehe ich etwas, wo man Daten drin abspeichern kann, die man da später auch wieder rauslesen kann. Versuch das mal mit einem Verzeichnis oder Socket.
Ich verstehe was mit beidseitig begrenzt gemeint ist, aber ob es der unbefangene Leser versteht, der es noch nicht weiß, bezweifle ich.
Muss ich noch mal drüber grübeln, wie man das besser formulieren könnte.
"können diese mit zusätzlichen Suchkriterien nach Mindest- und Maximaltiefe begrenzt werden." wäre eine Option, aber das kommt doch ohnehin beim -*depth-Parameter.
Hab' eine leichte Abwandlung davon eingearbeitet.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Hallo, ich finde die jüngsten Änderungen von noisefloor z.T. schon etwas übertrieben. Hin und wieder mal eine herzliche Formulierung lockert die Hirnzellen und erinnert daran, dass hier Menschen mit Herzblut schreiben. Mit den Leerzeilen kann man es m.E. auch übertreiben, wer keinen 26 " Bildschirm hat muss beim Editieren ständig lästig scrollen. Weiterhin finde ich es eher hilfreich, wenn Erläuterungen direkt an der zugehörigen Befehlsstruktur "kleben". Bei dem Komma in Zeile 404 bin ich mir ziemlich sicher, dass es falsch ist. Da es sich in Zeile 431 um ein Beispiel von vielen möglichen Falschpositionen handelt, fand ich "z.B." angemessen.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: find ... + klappt sehr wohl mit md5sum:
Mit "klappt nicht" meinte ich, dass im Ergebnis mit ';' kein Unterschied zu dem mit '+' erkennbar ist. Also die im Artikel gezeigte einzeilige Darstellung für md5sum mit + stimmt nicht mit der Realität überein. Ich hatte länger überlegt, welchen Befehl man deswegen besser für das Beispiel verwenden könnte und fand du . echo finde ich jedenfalls ein wenig zu banal. Wenn Dir was besseres einfällt, gerne.
(alt) * Ohne weitere Angaben gibt find die Namen der gefundenen Dateien aus: (neu) * Ohne weitere Angaben gibt find nur die gefundenen Dateinamen inkl. relativem Pfad aus:
Das "nur" würde ich weglassen,
Das "nur" sollte sich auf den Unterschied zu der Variante mit -ls beziehen, aber gut, kann von mir aus auch weg. Immerhin stand da vorher schon, auf was ich dauernd hinweise, find gibt "Namen von Dateien" aus, also "Dateinamen" oder auch Socketnamen etc.. Das Finden der Dateien selbst findet nicht statt, und im unwahrscheinlichen Fall eines Dateisystemfehlers existiert sie vielleicht auch nicht und im Fall eines Symlinks kann das erst recht vorkommen.
statt "inkl. relativem Pfad" würde ich, wenn überhaupt, "mit relativem Pfad" schreiben,
Gerne.
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.
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.
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. Oder meinst Du, dass das selbsterklärend ist, und nicht erläutert werden muss? So sind da evtl. 2 Sachverhalte in einem Satz etwas unglücklich verheiratet. In meiner Formulierung ist das zwar auch so, aber immerhin durch Gedankenstrich separiert.
Erinnert mich ein wenig an das Übersetzungsbeispiel von unserem Lateinlehrer Schmidt auf dem MPG: "Er schlug zuerst die Scheibe und dann den Weg nach Kürenz ein." Für die Nicht-Trierer: Kürenz ist ein Stadtteil von Trier.
Deine Änderungsanmerkung:
Verkomplizierung und Verwirrung durch "test" entfernt; "test" könnte so missverstanden werden, dass es dabei um das Testen eines Befehls in einem Testordner geht.
(war) find test/ -depth -name "c*" (ist) find -depth -name "c*"
Geht es ja auch.
Verstehe ich das richtig als Zustimmung? Ich finde, um so kürzer das Beispiel, um so deutlicher fällt der Unterschied mit dem -depth ins Auge.
Alt: | find test/ -name "c*" -delete
|
Löscht im Verzeichnis test und dessen Unterverzeichnissen alle Dateien, die mit 'c' beginnen.
Neu:
Löscht 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 z.B. mit rm .
Das löscht nicht alle Dateien, die mit c beginnen, sondern nur im aktuellen Verzeichnis und dessen Unterverzeichnissen. Und rm löscht allgemein nicht Verzeichnisse.
Stimmt, gleich 2 Fehler von mir! Dann stimmt aber das mit dem "allgemein üblich" nicht so ganz. Vorschlag: "..., wie z.B. bei rmdir üblich." Oder mit "... z.B. mit rm -dr ."
Hier war auch nebenbei ein Startverzeichnis gezeigt.
Fand ich eigentlich auch gut, aber darf das denn auch anders als "test" heißen wegen erwähnter Fehldeutungsmöglichkeit? Nicht weit vorher wird ja in Zsh. mit -delete empfohlen, erst ohne die "gefährliche Aktion" zu testen. Ich musste deshalb erst überlegen, ob es hier wieder um erstmal testen geht, bevor die realen Daten dran kommen.
(war) * die Kombination mit -print (ist) * Ausgabe erzwingen mit -print
Ohne Kombination mit anderen Befehlen muss man keine Ausgabe erzwingen, weil das der Defaultfall ist. Auch hier steht "Kombination" aus einem Grund.
Den Begriff "Kombination" sehe ich im Zusammenhang mit find schon für das Kombinieren von Suchkriterien "verbraucht". "DIE Kombination" klingt für mich direkt als Bezug auf den vorangehenden gleichnamigen Abschnitt. Sonst ist ja alles eine Kombination, und wir könnten dann z.B. alle "Aktionen" auch im Abschnitt "Kombinationen" unterbringen. Ich hatte auch über "Ausgabe veranlassen" nachgedacht, doch schien mir "erzwingen" treffender. Genau wäre z.B.: "... mit -print " kann dann weggelassen werden. Also statt hier die Funktion von touch zu erklären sollte man vielleicht besser allgemein darauf hinweisen, dass -exec die Default-Ausgabe von find verschluckt, und dass man sie mit -print wieder sichtbar machen kann. Man könnte also schreiben: "Weil touch nichts ausgibt und man dann deshalb keine Kontrolle darüber hat, was getan wurde, kann man so die Ausgabe/Ergebnisse von find wieder sichtbar machen." Man könnte auch darüber nachdenken, -print in die Tabelle der geläufigsten Aktionen aufzunehmen – ist vermutlich geläufiger als -fprint – und da dann dessen Anwendung kurz allgemein begründen.
* Meist empfiehlt sich -execdir statt -exec 325 find test -type d -execdir tar -cjf archiv.bz2 {} \;
325 find -type d -execdir tar -cjf archiv.bz2 {} \;
326 326 -execdir führt das Kommando aus dem Verzeichnis heraus aus, in dem die Datei gefunden wird. So wird also für jedes Verzeichnis ein archiv.bz2 vor O* Meist empfiehlt sich -execdir statt -exec 325 find test -type d -execdir tar -cjf archiv.bz2 {} \;
325 find -type d -execdir tar -cjf archiv.bz2 {} \;
326 326 -execdir führt das Kommando aus dem Verzeichnis heraus aus, in dem die Datei gefunden wird. So wird also für jedes Verzeichnis ein archiv.bz2 vor Ort angelegt.rt angelegt.
Das Startverzeichnis test drängt dem Leser die Tatsache auf, dass Dateien eben nicht im aktuellen Verzeichnis gefunden werden, und es so einen Unterschied macht.
Hm, eine Tatsache, die erst durch das Anführen von "test" geschaffen wurde, oder was verstehe ich da nicht? Jedenfalls kommt mit test auch Unsinn raus ... Archive namens archiv.bz2 wo jeweils eine unbekannte Datei namens archiv drin ist, siehe Anhang. Folgendes wird jedenfalls auch ausgeführt (im Verzeichnis test), kommt aber ähnlicher Unsinn bei raus:
Wieso hast Du das wieder weggemacht?
Weil es hier wie oben nicht um das Testen auf test-Daten geht, sondern um reale Daten.
70 sucht Dateien die n Zuordnungseinheiten belegen. Folgende Marker 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.
70 sucht Dateien die n Zuordnungseinheiten belegen. Folgende Etiketten können
Inwiefern ist Etiketten besser als Marker?
Weil laut Wörterbuch Marker im Deutschen leuchtend bunte Stifte sind und eine der Übersetzungen aus dem Englischen "Etikett" ist. Vielleicht wäre "Kennzeichner", "Einheiten", "Multiplikatoren" oder was ähnliches besser?
Bezeichnet dieser ein Verzeichnis – z.B. . – zählt dessen Inhalt schon zu Tiefe 1.
Hatten wir schon mal: Ein Punkt im Fließtext liest sich schlecht.
Stimmt, in dem Fall stünde im Befehlsaufruf aber tatsächlich . und nicht aktuelles Verzeichnis. Hm, was machen wir da? Vielleicht: Bezeichnet dieser ein Verzeichnis – z.B. implizit das aktuelle Verzeichnis – zählen dessen Einträge schon zu Tiefe 1.
"zählt dieses als Tiefe 1".
Nein, dieses aktuelle Verzeichnis selbst (.) zählt dann als Tiefe 0. Was soll das mit "dessen Inhalt"? Dessen Inhalt können ja weitere Unterverzeichnisse sein.
Dann nehmen wir doch besser "dessen Einträge" 😉
123 sucht im aktuellen Verzeichnis, findet also auch . . 121 sucht ab dem aktuellen Verzeichnis, findet also auch . . ... (viele mehr)
Hatten wir das nicht geklärt? Man sucht im Verzeichnis, nicht ab einem Verzeichnis, weil es hierarchisch ist, nicht sequentiell.
Das steht da schon seit letztem Jahr drin, ich dachte das sei in den gegebenen Fällen abgenickt.
Es geht um die Verschachtelung der Verzeichnisse, das sehe ich als eine Sequenz von Tiefe 1 bis ... . Auch in einer Hierarchie spricht man von "Ab Abteilungsleiter abwärts ...". Ich stolpere darüber, dass wenn ich im Verzeichnis mit der Suche beginne, das als Tiefe 0 sehe, was find aber bereits als Tiefe 1 sieht. 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 . 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.
Untersuch mal ein paar Userbeiträge, wie oft die in einem Verzeichnis oder ab einem Verzeichnis irgendwas tun.
Wenn sie in einem Verzeichnis etwas tun, z.B. Besitzer ändern, bleibt der Besitzer des Verzeichnisses unverändert, nicht aber, wenn sie das ab einem Verzeichnis tun. find Verzeichnis -exec chown fritz {} \; würde eben letzteres tun.
sucht nach den vollständigen Namen hausarbeit.odt.
Hm. hier sucht find also ausnahmsweise mal nach Namen, und nicht nach Dateien. 😀 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. sucht nach Einträgen mit dem vollständigen Namen hausarbeit.odt
Es bläht die Sätze sinnlos auf.
Tut's, aber nicht unbedingt sinnlos wegen der Verwechslungsmöglichkeit mit der Funktionalität mit grep . Aber gut, hier könnte ich nachgeben.
findet nur Verzeichnisse, aber keine sonstigen "Dateien".
Sinnlose Anführüngsstriche.
Hm, weil es eben auch keine Sockets etc. findet. Korrekt wäre: findet nur Verzeichnisnamen, aber keine sonstigen.
sucht von Verzeichnistiefe 3 bis 5.
sucht in Verzeichnistiefe 3 bis 5.
Ersteres klingt für mich wie "sucht von Pontius bis Pilatus" oder "von Hamburg bis München". Aber auch hier könnte ich nachgeben. Änderung um nachträgliches Beifügen von Anhängen zu provozieren, mal sehen ob's klappt. Siehe: https://forum.ubuntuusers.de/topic/kann-keine-anhaenge-meinem-post-beifuegen
- test1.tar.bz2 (761 Bytes)
- Download test1.tar.bz2
- archiv.bz2 (1.5 KiB)
- Download archiv.bz2
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
UlfZibis schrieb: Hin und wieder mal eine herzliche Formulierung lockert die Hirnzellen und erinnert daran, dass hier Menschen mit Herzblut schreiben.
Commit-Messages sind gerne kurz & knapp — auch deine eigenen und das ist gut so. Wenn du jetzt versuchst so eine kurze Meldung emotional auszulegen, dann geht das zwangsweise schief. Lange Meldungen sind gut gemeint, aber machen es in dem tabellarischen Verlauf schwerer, auf einen Blick zu erfassen, worum es geht. Die (wirklich sehr oberflächliche) Änderung von noisefloor sieht eigentlich gut aus. Schwer nachzuvollziehen warum du dir davon auf die Füße getreten fühlst. Es ist beim Wiki immer so, daß andere Leute an deinem Zeug herumeditieren — genauso wie du ja auch an anderer Leute Zeug herumeditierst. Du könntest am ehesten noch so argumentieren, daß das im Moment "deine" Baustelle ist und es besser wäre, solche Sachen — egal wie trivial — einfach hier anzumerken. Da sind auch Stilfragen mit drin. Bei z.B. würde ich sagen daß das zu häufig verwendet wird und gerade bei z.B. . besonders unglücklich aussieht. Kleiner Vorschlag habe ich noch zu /home/otto/, das zu /home/ottifant oder /home/otto/toto-lotto/ zu machen und # falsch! hinter den Befehl zu schreiben. Befehle werden gerne blind kopiert und /home/otto könnte tatsächlich so existieren...
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
frostschutz schrieb: Hin und wieder mal eine herzliche Formulierung lockert die Hirnzellen und erinnert daran, dass hier Menschen mit Herzblut schreiben.
Commit-Messages sind gerne kurz & knapp —
Obiges bezog sich auf das Löschen von: "Krasser noch ... Das ist nicht sehr intuitiv, also Obacht." Die Formulierung war allerdings nicht von mir, doch ich fand sie herzergreifend nett.
Die (wirklich sehr oberflächliche) Änderung von noisefloor sieht eigentlich gut aus. Schwer nachzuvollziehen warum du dir davon auf die Füße getreten fühlst.
Danke für's Mitgefühl, manchmal schwächelt man halt mal. 😉
Kleiner Vorschlag habe ich noch zu /home/otto/, das zu /home/ottifant
Nett! und # falsch! hinter den Befehl zu schreiben.
Gute Idee, werde ich einbauen.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7658
|
UlfZibis schrieb: Obiges bezog sich auf das Löschen von: "Krasser noch ... Das ist nicht sehr intuitiv, also Obacht." Die Formulierung war allerdings nicht von mir, doch ich fand sie herzergreifend nett.
Aah, da hab ich dich falsch verstanden, sorry. 😀
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo,
Hallo, ich finde die jüngsten Änderungen von noisefloor z.T. schon etwas übertrieben.
Hin und wieder mal eine herzliche Formulierung lockert die Hirnzellen und erinnert daran, dass hier Menschen mit Herzblut schreiben.
Mit den Formulierung wäre der Artikel nicht zurück ins Wiki gekommen. Weil: zu unsachlich für's Wiki. Gruß, noisefloor
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29067
Wohnort: WW
|
Hallo,
Mit den Leerzeilen kann man es m.E. auch übertreiben, wer keinen 26 " Bildschirm hat muss beim Editieren ständig lästig scrollen.
Habe ich auch nicht. Meine Laptops haben einen 15.4" bzw 14.1" Bildschirm.
Weiterhin finde ich es eher hilfreich, wenn Erläuterungen direkt an der zugehörigen Befehlsstruktur "kleben".
Die Darstellung im fertigen Artikel ist die gleiche. Wenn du alles hintereinander pappst, sind z.B. Klammerfehler viel schwerer zu sehen. Natürlich kann du weiter den Quelltext ohne Leerzeilen schreiben, dass hat auch keine Einfluss darauf, ob ein Artikel für's Wiki für gut (oder nicht) befunden wird. Nur wenn ich schon editieren, dann baue ich die direkt ein. Andersrum würde ich aber auch "nur" für Leerzeilen keinen Edit starten. Ansonsten zum Artikel: soweit fertig? Fertigstellungsdatum ist ja in 2h36 min 😉 Oder brauchst du noch 5 bis 6 Seiten Diskussion mit user_unknown? *SCNR* Gruß, noisefloor
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
noisefloor schrieb: Mit den Leerzeilen kann man es m.E. auch übertreiben, wer keinen 26 " Bildschirm hat muss beim Editieren ständig lästig scrollen.
Habe ich auch nicht. Meine Laptops haben einen 15.4" bzw 14.1" Bildschirm.
OK, dann bin ich jetzt als scroll-faul geoutet. 😢
Weiterhin finde ich es eher hilfreich, wenn Erläuterungen direkt an der zugehörigen Befehlsstruktur "kleben".
Die Darstellung im fertigen Artikel ist die gleiche. Wenn du alles hintereinander pappst, sind z.B. Klammerfehler viel schwerer zu sehen.
Welche Art von Klammerfehlern meinst Du denn in dem Zusammenhang? Mit oben und unten einer Leerzeile muss man halt viel genauer gucken, zu welcher Befehlszeile der Begleittext gehört. Oft ist die Befehlszeile ja auch Teil des Satzes drumherum; den dann durch eine Absatzmarkierung zu spalten, finde ich schon gewagt. Und wenn man sich innerhalb eines Aufzählungspunktes bewegt, geht der "Schönstil" eh über die Wupper. Aber Danke für's Feedback. Kommaregeln: Bei Oder- und Und-Verknüpfungen von mehreren Optionen helfen Klammern, Fehler zu vermeiden.
Wenn man diesem Satz das Beiwerk raubt Klammern helfen, Fehler zu vermeiden.
fällt ins Auge, dass da IMHO kein Komma hingehört, oder hab' ich in der Schule da was verpasst? (Ist erst durch Deine vorletzte Änderung reingekommen.) Im Grunde genommen zählt "Fehler vermeiden helfen" wie "putzen helfen" oder "Gassi gehen" als einzelnes Verb. Hauptwortzusammensetzungen: misst für alle darauf folgenden -xtime und -xmin Kriterien ...
Wenn man diesen Halbsatz semantisch, aber nicht grammatikalisch, ändert misst für alle darauf folgende Zeit Kriterien ...
fällt ins Auge, dass da IMHO doch ein Bindestrich hingehört, oder? Es sei denn, man wollte Kriterien messen 😉 (Das vorher kleine "k" gehörte allerdings GROSS.) (Das 'n' gehört möglicherweise auch weg.) Ansonsten zum Artikel: soweit fertig? Fertigstellungsdatum ist ja in 2h36 min 😉
Evtl. auch als 24 h 48 min – mittlerweile – bis 31.03. zu verstehen 😉 Oder brauchst du noch 5 bis 6 Seiten Diskussion mit user_unknown? *SCNR*
Meine Kristallkugel wird leider gerade poliert ... 😕 ... und interessant, wenn ich ls im Terminal eingebe, starte ich ein Programm, aber mit ls -al führe ich einen Befehl aus laut Syntax (Abschnitt „Textformatierung“); warum heißt es denn Befehlszeile und nicht Programmstarter? Ein Programm ist ein Subjekt und das bezeichnende Substantiv wird deshalb im Deutschen auch groß geschrieben, aber find, mv etc. bezeichnen doch eher ein Verb in Befehlsform. Und so Beispiele wie du im Text erhöhen auch nicht unbedingt das Leseverständnis. Gab es mal eine Forumsdiskussion darüber, bevor das so festgelegt wurde?
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Solche Nebensätze mit zu und Verb werden stets mit Komma getrennt.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Benno-007 schrieb: Solche Nebensätze mit zu und Verb werden stets mit Komma getrennt.
Interessant, wieder was dazu gelernt. Also:
Schrubber helfen, zu putzen. Nachbarn helfen Gassi gehen. Peter ist bereit, zu laufen. Papa hilft, zu spülen. Mit Rucksack zu laufen, ist aber mühsam.
|