noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29044
Wohnort: WW
|
Hallo,
ob Tabelle ohne Titeltext technisch überhaupt geht.
Klar geht das. Üblich und gängig ist aber bei Tabellen für Optionen, dass diese eine Titelzeile und Spaltenüberschriften haben.
Besteht darüber allgemeiner Konsens, dass das immer so sein muss?
Muss - nein. Sollte, weil schöner: ja. Gruß, noisefloor
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
noisefloor schrieb: Wobei es bei Wikiartikel halt nicht um dein Sprachempfinden geht,
Das würde ich auch niemals in Anspruch nehmen.
sondern um Inhalt und Verständlichkeit.
... wird durch Abwandlung in Wiederholung nicht besser, ich würde sogar sagen, leidet eher unter dem dadurch verursachten Stolpern beim Lesen. noisefloor schrieb: Besteht darüber allgemeiner Konsens, dass das immer so sein muss?
Muss - nein. Sollte, weil schöner: ja.
Also das optische Empfinden ist wichtig, nicht aber das sprachliche, oder wie?
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb: @ noisefloor ... Das ist nur ein Zwischenbericht. Ich würde ja gerne den Artikel folgendermaßen beginnen: 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. Wer von Dateisystemverzeichniseinträgen liest erwartet sprachlich auch erst mal nichts weiter, als Dateien. Gewinn ist null, es schreckt nur ab. 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?
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.
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. 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? 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.
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. Andererseits werden Optionen im Artikel nicht dargestellt aber im Absatz davor darauf verwiesen, dass es sowas gibt und in der manpage genaueres zu finden ist. Ich würde die Optionen daher hier rauswerfen, denn wer dazu ohne unsere Hilfe vorgedrungen ist, der findet da auch raus, was es mit der Reihenfolge auf sich hat.
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.
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. Die User suchen auch, erlaube ich mir zu postulieren, in aller erster Linie Dateien im engeren Sinne.
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.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Nachtrag:
findet nur Verzeichnisse, aber keine sonstigen "Dateien".
Die Anführungsstriche sind überflüssig, sinnlos und zu streichen (und Dateien auch nicht durch Dateisystemverzeichniseinträge zu ersetzen, bitte).
|
frustschieber
Ehemalige
Anmeldungsdatum: 4. Januar 2007
Beiträge: 4259
|
Stand der Dinge dieser Überarbeitung? Gruss
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
frustschieber schrieb: Stand der Dinge dieser Überarbeitung? Gruss
Hallo, wie schon anlässlich der letzten Bearbeitung kommentiert, hatte mich eine langwierige Grippe heimgesucht. Nun habe ich das dadurch Liegengebliebene so langsam aufgearbeitet, und kann mich in den nächsten Tagen wieder mit dem Artikel beschäftigen. Gruß Ulf
|
frustschieber
Ehemalige
Anmeldungsdatum: 4. Januar 2007
Beiträge: 4259
|
Hoffentlich bist Du wieder gesund! Alles andere eilt ja nicht. Gruss
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29044
Wohnort: WW
|
Hallo, was ist denn hier Stand der Dinge, UlfZibis? Für Edits an anderen Artikel hast du ja Zeit, warum geht es hier dann nicht weiter? Gruß, noisefloor
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
noisefloor schrieb: was ist denn hier Stand der Dinge, UlfZibis?
Danke der Nachfrage.
Leider kommt ständig was neues dazwischen, z.B. RAM-Fehler, steht aber dick und fett auf der ToDo-Liste auf meinem Tisch. Für Edits an anderen Artikel hast du ja Zeit, warum geht es hier dann nicht weiter?
Kleine Dinge gehen immer, müllen sonst die ToDo-Liste zu, und erledigt machen sie einen freieren Kopf. Für den find-Artikel brauche ich mindestens 3 Stunden störungsfreie Zeit ohne Termindruck, und das am besten an mehreren Tagen hintereinander, sonst macht das Einarbeiten in die aufwändige Thematik keinen Sinn. Ab Montag müsste wieder Luft sein.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Hallo user_unknown, wie Du sicher bemerkt hast, war ich "fleißig". Könntest Du nun bitte mal meine Änderungen begutachten, ob Dir vielleicht was "aufstößt"? Gruß Ulf
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Jo, hab' mir eine Benachrichtigung auf Artikeländerungen gesetzt und werde daher eh über jede solche informiert. Wenn ich mich nicht melde kam ich noch nicht dazu, ist es mir zuviel, zu anstrengend oder ich bin einfach einverstanden. ☺ Letzteres hier.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Wenn ich mich nicht melde kam ich noch nicht dazu, ist es mir zuviel, zu anstrengend oder ich bin einfach einverstanden. ☺ Letzteres hier.
Fein. Dann werde ich mich die Tage noch mal diesem leidigen Thema widmen: Dateien vs. Dateinamen vs. Einträge (im Dateiverzeichnis)
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Da war noch eine ältere Antwort in der Pipeline ...
Man sucht sie aber oft eben nicht auf, sondern informiert sich nur mit find.
... und zuvor muss find erstmal die Einträge im Dateiverzeichnis aufsuchen um ihren Inhalt mit den gegebenen Suchkriterien zu vergleichen. Dann erst informiert find darüber, welche Einträge zu den vorgegebenen Suchkriterien passen. Die Dateien selbst bleiben da erst mal außen vor und es interessiert auch nicht, ob mit den gefundenen Einträgen wirklich Dateien oder was anderes verknüpft sind.
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.
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.
Mein Favorit ist deshalb im Sinne der Würze der Kürze: Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch z.B. Verzeichnisse Dateien sind, und mit den gleichen Methoden aufgesucht werden.
Von dem z.B. hatte ich Dich doch schon abgebracht!
OK - ich kauf es Dir ab. Du bekommst Deinen Vorwärtsschrägstrich und dafür opferst Du das z.B.!
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". 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.
Wie gesagt, find sucht die Datei. Wenn es keine gibt wird trotzdem gesucht, weil man das erst nach der Suche weiß, nicht nach der Aufsuche, und auch nicht nach einem Zugriff ins Nichts.
Auch hier würde ich sagen, find orientiert sich erstens nur nach deren Einträgen im Dateiverzeichnis, wie auch alle anderen Befehle, auf die sich der Spruch ja auch bezieht, und zweitens werden damit im Fall von GNU/Linux nicht nur Dateien verzeichnet.
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.
Nein. Wer den find-Befehl noch nicht kennt, der wird wohl die Suche des Browsers nutzen oder sich auf dem Dachboden strangulieren. Wer find kennengelernt hat, wird die Browsersuche wohl nie mehr benutzen, zumindest nicht die von Thunar.
Bei den mir bekannten Datei-Browsern unter Linux ist das leider immer noch so. Der Windows Explorer bietet da tatsächlich mehr, und wenn man von da kommt, versucht man sich naiv und der Bequemlichkeit wegen mit Thunar etc. eben auch so lange es eben nur geht. Auch ich habe find erst mal mindestens 2 Jahre umgangen, und heute weiß ich warum. 😈
Ich habe eben in meinem Homeverzeichnis versucht mit ?o?/ das Verzeichnis job zu finden, das unmittelbares Unterverzeichnis ist. Dass ich ein Verzeichnis suche konnte ich nicht sagen, ob der schließende Slash (vorw. Schrägstrich) zulässig ist weiß ich nicht, die Suche ist losgelaufen, aber sie läuft noch. Ah, ja, jetzt fertig, hat nichts gefunden. Für Größe, Alter habe ich auch nichts gesehen. Das ist ja armseelig! Halt, doch, nach "letzter Woche" kann man suchen. Ist wohl ein Gerät für Letztwochler. Ordner kann man, neben einer Handvoll Dateitypen auch auswählen, aber 3 Zeichen, der mittlere o, kann man nicht als Kriterium eingebwen. Dateinamenserweierungen (sic!) kann man auch eingeben, wahrscheinlich nur komplett und nur eine, keine Muster. Ein Werkzeug, so nützlich wie ein Ananasschäler. Breiten wir den Mantel des Schweigens über die Dateibrowsersuche.
Gute Idee, zumindest unter Linux! EDIT: Genau genommen sind aus der Sicht von find Sockets etc. eher dasselbe wie Dateien als Verzeichnisse. Nur Verzeichnisse müssen speziell verarbeitet werden ... öffnen, Einträge auswerten usw.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
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.
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".
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.
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.
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.
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. 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.
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?
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".
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.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb: user_unknown schrieb: Da war noch eine ältere Antwort in der Pipeline ...
Der ist eine Woche lang nicht widersprochen worden, womit die Einspruchsfrist endgültig abgelaufen ist, und die Formulierungen rechtskräftig gültig geworden sind, lt. Wikigesetz 732 (5) Ziffer a.
Man sucht sie aber oft eben nicht auf, sondern informiert sich nur mit find.
... und zuvor muss find erstmal die Einträge im Dateiverzeichnis aufsuchen um ihren Inhalt mit den gegebenen Suchkriterien zu vergleichen. Dann erst informiert find darüber, welche Einträge zu den vorgegebenen Suchkriterien passen. Die Dateien selbst bleiben da erst mal außen vor und es interessiert auch nicht, ob mit den gefundenen Einträgen wirklich Dateien oder was anderes verknüpft sind.
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. Das Dateisystem ist integraler Bestandteil des OS, deswegen kann das OS nicht die Dateien aufsuchen, so wie Du auch nicht Deinen Magen aufsuchen kannst. Aber suchen kannst Du Deinen Magen.
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. 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? Der User sucht aber i.d.R. nicht, oder nur mittelbar, die Bezeichnung. Er sucht das Bezeichnete, sprich, die Datei. Denn nicht die Bezeichnung hat eine -size +10M, sondern die Datei. Nicht die Bezeichnung ist soundsoalt, sondern die Datei.
Mein Favorit ist deshalb im Sinne der Würze der Kürze: Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch z.B. Verzeichnisse Dateien sind, und mit den gleichen Methoden aufgesucht werden.
Von dem z.B. hatte ich Dich doch schon abgebracht!
OK - ich kauf es Dir ab. Du bekommst Deinen Vorwärtsschrägstrich und dafür opferst Du das z.B.!
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.
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. Oder Adressbezeichnungseintragsbezeichnungen. Wir können auch noch 2-3 Indirektionen mehr aufbauen. Adressverzeichniseintragsnamensäquivalente wäre doch hübsch! Und Personen ersetzen wir durch Personenbehausungsbewohner. Personenbehausungsbewohnernamenbezeichnungen um es ganz korrekt zu formulieren, und später reden wir dann, nachdem wir das klar gemacht haben, nur noch von Bezeichnungen. Oder von Personenbehausungsbewohnerbezeichnungsverzeichniseinträgen und später dann von Einträgen. Wer's nicht rafft bekommt einen Eintrag ins Klassenbuch.
Wie gesagt, find sucht die Datei. Wenn es keine gibt wird trotzdem gesucht, weil man das erst nach der Suche weiß, nicht nach der Aufsuche, und auch nicht nach einem Zugriff ins Nichts.
Auch hier würde ich sagen, find orientiert sich erstens nur nach deren Einträgen im Dateiverzeichnis, wie auch alle anderen Befehle, auf die sich der Spruch ja auch bezieht, und zweitens werden damit im Fall von GNU/Linux nicht nur Dateien verzeichnet.
Ja, doch, weil das alles ja definitionsgemäß Dateien sind. ☺
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.
Nein. Wer den find-Befehl noch nicht kennt, der wird wohl die Suche des Browsers nutzen oder sich auf dem Dachboden strangulieren. Wer find kennengelernt hat, wird die Browsersuche wohl nie mehr benutzen, zumindest nicht die von Thunar.
Bei den mir bekannten Datei-Browsern unter Linux ist das leider immer noch so. Der Windows Explorer bietet da tatsächlich mehr, und wenn man von da kommt, versucht man sich naiv und der Bequemlichkeit wegen mit Thunar etc. eben auch so lange es eben nur geht. Auch ich habe find erst mal mindestens 2 Jahre umgangen, und heute weiß ich warum. 😈
Das Wiki zielt nicht in erster Linie auf Windowsumsteiger und setzt nicht irgendwelche Windowsgewohnheiten voraus. Außerdem, das letzte Mal, als ich mit dem Windowsexplorer nach einer Datei gesucht habe, da habe ich mit einem Editor eine Textdatei mit dem Inhalt "test" erstellt und "test" genannt, und dann gesagt, es soll in dem Verzeichnis, in dem es keine andere Datei gab, nach einer Textdatei mit dem Inhalt "test" gesucht werden. Das Ergebnis war beschämend...
(...) Ein Werkzeug, so nützlich wie ein Ananasschäler. Breiten wir den Mantel des Schweigens über die Dateibrowsersuche.
Gute Idee, zumindest unter Linux!
Meine Windowserfahrungen jetzt aufzufrischen, um Recht zu behalten, erspare ich mir an dieser Stelle.
EDIT: Genau genommen sind aus der Sicht von find Sockets etc. eher dasselbe wie Dateien als Verzeichnisse. Nur Verzeichnisse müssen speziell verarbeitet werden ... öffnen, Einträge auswerten usw.
Du vermischst hier die Kategorien, einmal das Verzeichnis als etwas das gesucht wird - und da sind Verzeichnisse in Verzeichnissen das gleiche wie Dateien in Verzeichnissen - und einmal wie die Suche voranschreitet, da sind Verzeichnisse etwas anderes, weil sich der Schalter -maxdepth z.B. darauf auswirkt. Eine Datei, die weitere Dateien enthält, etwa ein Ziparchiv, wird nicht weiter durchsucht, außer man würde mit einer der exec-artigen Möglichkeiten ausdrücklich dafür sorgen. Langer Rede kurzer Sinn:
Ein Dateiverzeichnis enthält als Einträge Dateien. Würde das Verzeichnis nicht Dateien, sondern Pilze enthalten, wäre es kein Dateiverzeichnis sondern ein Pilzverzeichnis. Der Begriff Dateiverzeichniseinträge steigt also unnötig von den Dateien zum Verzeichnis auf, nur um von dort wieder zu den Einträgen hinabzusteigen. Dein Einwand hier ist, dass nicht die Dateien selbst, sondern nur ihre Bezeichner im Dateiverzeichnis stehen. Korrekt müsste man also nicht von einem Dateiverzeichnis, sondern von einem Dateibezeichnerverzeichnis reden. 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! Und wie gesagt, da die Suche immer scheitern kann ist es eine Suche, keine Aufsuche. Wir müssen nicht aufstehen, und über die CD-Schublade versuchen ins Dateisystem einzudringen, um dort unsere Dateien aufzusuchen, wir können sie so suchen, von der Tastatur aus, mit find. ☺
|