user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
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.
Bisher: >
Startverzeichnis(se)
Es wird der Verzeichnisbaum ab den angegebenen Startverzeichnissen durchsucht, was mit zusätzlichen Suchkriterien begrenzt werden kann.
Was soll das sein, ein Regelfall? Wenn es kein Filter verhindert? "Ist zu beachten..." ist so ein Referenzhandbuchsprech. Wer die Kommandos ausprobiert, der sieht sofort, dass das Startverzeichnis enthalten ist, so es ein Verzeichnis überhaupt ist, wenn man schon superkorrekt sein will. | find a.txt b.bmp c.jpg j.sh -ls
|
sind gar keine Startverzeichnisse. Die Lösung ist jetzt nicht, den Fall auch noch in die Erklärung zu pfriemeln. Ich würde den Zinnober weglassen. Die Leute sollen es ausprobieren und selbst sehen.
Es geht hier um Varianten des Startpunktes.
Keine Angabe eine Angabe (relativer Pfad) relativer Pfad aber Oberverzeichnis mehrere Angaben eine Angabe absoluter Pfad Wurzelverzeichnis
Es ist vom Typ der Angabe gedacht, nicht von einem gewollten Ergebnis. Das -mindepth bricht aus dem Schema aus, so dass es kein Schema mehr ist, denn -mindepth ist eine Option, kein Startpunkt. Zwei Auszeichnungen sind auch mindestens eine zuviel: nur im.
sucht im Unterverzeichnis foo des aktuellen Verzeichnisses.
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.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Wenn erst in den Unterverzeichnissen gelöscht wird kann ein dadurch leeres Oberverzeichnis auch gelöscht werden, umgekehrt nicht. Vorschlag: +dadurch -Ober
Gute Idee, aber ich würde das so schreiben: Wenn erst in den Verzeichnissen gelöscht wird kann ein dadurch leeres auch selbst gelöscht werden, umgekehrt nicht.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29045
Wohnort: WW
|
Hallo, ist die Überarbeitung fertig oder fehlt noch was? Gruß, noisefloor
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: 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?
Ich verstehe nicht ganz, was Du meinst. Für mich ist der Text im Einleitungstext "Die folgende Tabelle zeigt ..." schwarz, außer den anklickbaren Links, die in braun gehalten 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+ .
Ich meinte, dass "normale Dateien" eine Ansammlung von Bytes beinhalten, die je nach Kodierung mit entsprechenden Programmen gelesen und bearbeitet werden können, während diese Bytes bei Verzeichnissen als Liste mit Verweisen zu weiteren Dateisystemobjekten interpretiert werden.
Im Ernst: Wozu? Was sonst?
OK, klingt schon etwas geschwurbelt, können wir weglassen. Und wieso aufgesucht? Um ihnen die Aufwartung zu machen?
Weil "gefunden" ein Suchen voraussetzt. Wäre "gesucht" oder "eingetragen" bzw. "... die auf gleiche Art eingetragen sind" besser?
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!
Wenn ich in ein Haus (=Verzeichnis) reingehe, ist alles, was sich im Erdgeschoss befindet, nach meinem gewöhnlichem Verständnis in der Ebene/Tiefe 0, das in der 1. Etage in der Ebene/Tiefe 1. Find findet aber in Tiefe 0 keinen Inhalt, sondern das Haus, und in Tiefe 1 den Inhalt vom Erdgeschoss. Um das erst mal kapieren zu können, wählte ich die entsprechende Zählweise. Zumindest das Unter- sollten wir aber weglassen.
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 ).
Warum die Erläuterungen in Klammern? Ich denke die Bezüge sind auch daohne klar und der Satz wird dann lesbarer. Fehler von mir. Ich wollte "reguläre Dateien" (wie schon weiter oben bei -type T verwendet) schreiben. Gekauft! Neue Variante: ... sucht ab der UnterVerzeichnistiefe 3, und berücksichtigt nur reguläre Dateien mit der Endung .avi und die größer als 5 MiB sind.
Bei Dateitrenner denke ich erst, es geht um das Trennen mehrerer Dateien, nicht darum den Pfad der Datei vom Namen zu trennen.
Fehler von mir, im Englischen wird name separator verwendet, also Namenstrenner.
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. ☺
Wie war hier nochmal unser Kompromiss, so? : Will man mittels Pfaden oder Teilen davon suchen, kommt man mit -name nicht weiter. Das Suchkriterium -path ist hier die Lösung, denn es erlaubt die Verwendung des Namenstrenners / .
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb: user_unknown schrieb: 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?
Ich verstehe nicht ganz, was Du meinst. Für mich ist der Text im Einleitungstext "Die folgende Tabelle zeigt ..." schwarz, außer den anklickbaren Links, die in braun gehalten sind.
Da ging es um die Farben im Wiki im Vergleichmodus allgemein. Würde ich jetzt nicht mehr weiter diskutieren wollen.
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+ .
Ich meinte, dass "normale Dateien" eine Ansammlung von Bytes beinhalten, die je nach Kodierung mit entsprechenden Programmen gelesen und bearbeitet werden können, während diese Bytes bei Verzeichnissen als Liste mit Verweisen zu weiteren Dateisystemobjekten interpretiert werden.
So kann man nicht vergleichen. Bei dem einen zählst Du 3 Eigenschaften auf, und wendest Dich dem anderen zu, ohne zu prüfen, ob die Eigenschaften da auch vorhanden sind, sondern wendest Dich einfach anderen Kriterien zu, die Du wiederum bei den ersten gar nicht ausgeschlossen hast. "Ich meinte, dass "normale Dateien" eine Ansammlung von Bytes beinhalten, die je nach Kodierung mit entsprechenden Programmen gelesen und bearbeitet werden können", während Verzeichnisse keine Ansammlung von Bytes beinhalten? Nicht kodiert sind? Nicht mit entsprechenden Programmen gelesen und bearbeitet werden können? Das ist als ob man sagt: Ein Pferd hat 2 Ohren und 4 Beine während ein Schwein ein Ringelschwänzchen hat. Man kann Verzeichnisse wie Dateien öffnen, lesen, kopieren. Sie haben ein Erstelldatum, ein Datum der letzten Änderung, einen Eigentümer. Auf die Feinheiten des Dateisystems würde ich mich nicht einlassen, weil ich keine Ahnung davon habe.
Im Ernst: Wozu? Was sonst?
OK, klingt schon etwas geschwurbelt, können wir weglassen. Und wieso aufgesucht? Um ihnen die Aufwartung zu machen?
Weil "gefunden" ein Suchen voraussetzt. Wäre "gesucht" oder "eingetragen" bzw. "... die auf gleiche Art eingetragen sind" besser?
Ich habe schon 5 Euro auf der Straße gefunden, die ich nicht gesucht habe. Ich kann meine Mutter suchen ohne sie aufzusuchen und aufsuchen, ohne sie zu suchen. Gesucht oder gefunden wäre besser. Noch sehr viel schlechter wäre "... die auf gleiche Art eingetragen sind", was soll denn das heißen (rhetorische Frage)?
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!
Wenn ich in ein Haus (=Verzeichnis) reingehe, ist alles, was sich im Erdgeschoss befindet, nach meinem gewöhnlichem Verständnis in der Ebene/Tiefe 0, das in der 1. Etage in der Ebene/Tiefe 1. Find findet aber in Tiefe 0 keinen Inhalt, sondern das Haus, und in Tiefe 1 den Inhalt vom Erdgeschoss. Um das erst mal kapieren zu können, wählte ich die entsprechende Zählweise. Zumindest das Unter- sollten wir aber weglassen.
Wo man zu zählen beginnt ist Konventionssache. Wenn ich einen Karton im Karton im Karton habe, und in einem sitzt eine Katze, dann würde ich sagen die Katze ist im Karton der Tiefe 1, 2 oder 3. Beweisphoto. Wieso soll ich die Zählung mit 0 beginnen, wenn das nur zu dem Problem führt, dass ich ständig mit meiner Erklärung um 1 danebenliege? Etagen eines Hauses sind nicht geschachtelt und das Erdgeschoss hat einen eigenen Namen. Daher, und weil es auch noch Kellergeschosse haben kann, taugt es wenig als Analogie. Unterverzeichnis, das fiel mir jetzt auf, ist aus folgendem Grund sinnvoll. Wenn ich in /home/honk bin, und Bilder in /home/honk/bilder/2016/04 habe, und meine Suche beginnt: | find bilder -mindepth 2 ...
|
dann bezieht sich das Unter in Unterverzeichnis auf Bilder. Es könnte sich ja auch um eine absolute Verzeichnistiefe handeln.
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 ).
Warum die Erläuterungen in Klammern? Ich denke die Bezüge sind auch daohne klar und der Satz wird dann lesbarer.
Es zeigt, welche Elemente zusammengehören und es gibt Leute die kein Englisch können oder nur sehr schlecht.
Fehler von mir. Ich wollte "reguläre Dateien" (wie schon weiter oben bei -type T verwendet) schreiben. Gekauft!
Ok.
Neue Variante: ... sucht ab der UnterVerzeichnistiefe 3, und berücksichtigt nur reguläre Dateien mit der Endung .avi und die größer als 5 MiB sind.
find -mindepth 3 -type f -name "*.avi" -size +5M Beginnt die Suche ab Unterverzeichnistiefe 3 (-mindepth 3 ) und findet nur gewöhnliche Dateien (-type f ) mit der Endung .avi (-name "*.avi") die mindestens 5 MiB groß sind (-size +5M ).
Bei Dateitrenner denke ich erst, es geht um das Trennen mehrerer Dateien, nicht darum den Pfad der Datei vom Namen zu trennen.
Fehler von mir, im Englischen wird name separator verwendet, also Namenstrenner.
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. ☺
Wie war hier nochmal unser Kompromiss, so? : Will man mittels Pfaden oder Teilen davon suchen, kommt man mit -name nicht weiter. Das Suchkriterium -path ist hier die Lösung, denn es erlaubt die Verwendung des Namenstrenners / .
Gefällt mir nicht, aber die Urversion gefällt mir auch nicht. Wenn das jemand sucht, sucht er vielleicht eher nach "Verzeichnisname" und ob da ein Slash drin ist oder nicht ist gar nicht das Kriterium oder die Hürde. Wenn man Code in einem Projekteordner in allen src-Verzeichnissen sucht (a/src, b/src, c/src, ...) , dann kann man nicht | find -name "*src*" -type f
|
suchen, weil -name nur den reinen Dateinamen anschaut.
Vorschlag:
Path
Sucht man nach Verzeichnisnamen kommt man mit '-name' nicht weiter, da das nur den reinen Dateinamen berücksichtigt. Der Parameter '-path' erlaubt die Suche nach Pfadnamensteilen; mit Hilfe des Slashs '/' auch über Verzeichnisnamensgrenzen hinweg:
findet '~/fotos/2013/Juni' und '~/musik/2013/Juli' aber nicht '~/dokumente/2013-Juni'.
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Hm, hätte nicht gedacht, dass es so schwierig ist, beidseitig zufriedenstellende Formulierungen zu finden. Liegt vielleicht an unterschiedlichem Sprachgebrauch in Ost und West user_unknown schrieb: UlfZibis schrieb: Ich meinte, dass "normale Dateien" eine Ansammlung von Bytes beinhalten, die je nach Kodierung mit entsprechenden Programmen gelesen und bearbeitet werden können, während diese Bytes bei Verzeichnissen als Liste mit Verweisen zu weiteren Dateisystemobjekten interpretiert werden.
So kann man nicht vergleichen. Bei dem einen zählst Du 3 Eigenschaften auf, und wendest Dich dem anderen zu, ohne zu prüfen, ob die Eigenschaften da auch vorhanden sind, sondern wendest Dich einfach anderen Kriterien zu, die Du wiederum bei den ersten gar nicht ausgeschlossen hast.
Verstehe nicht von welchen 3 Eigenschaften Du sprichst und auch sonst nur Bahnhof. 🙄
... während Verzeichnisse keine Ansammlung von Bytes beinhalten?
Doch, das schrieb ich doch mit "... während diese Bytes bei Verzeichnissen ..." Nicht kodiert sind?
Doch auch, werden aber "speziell" interpretiert, sind also nicht mit einem Anwendungsprogramm wie z.B. Texteditor, LibreOffice, GIMP etc. les- und bearbeitbar, sind halt Daten über Verweise zu weiteren Dateien, also keine "eigentlichen" Nutzdaten. Nicht mit entsprechenden Programmen gelesen und bearbeitet werden können?
An welches Programm denkst Du da, mit dem man Dateien vom -type d lesen und bearbeiten kann ❓ Das kommt z.B. dabei heraus, wenn man die hier 4096 Bytes eines Verzeichnisses lesen will (8 Blöcke à 512 Bytes):
ich@ThinkPad-T500:~$ ls -ald Videos
drwxr-xr-x 2 ich ich 4096 Aug 11 17:22 Videos
ich@ThinkPad-T500:~$ dd if=Videos count=8 of=Videos.dir
dd: Fehler beim Lesen von 'Videos': Ist ein Verzeichnis
0+0 Datensätze ein
0+0 Datensätze aus
0 bytes copied, 0,000545748 s, 0,0 kB/s
Man kann Verzeichnisse wie Dateien öffnen, lesen, kopieren.
Eben nicht so einfach, siehe oben. Und beim Kopieren wird nicht nur das Verzeichnis, sondern es werden auch sämtliche Dateien, auf die das Verzeichnis verweist, kopiert. Sie haben ein Erstelldatum, ein Datum der letzten Änderung, einen Eigentümer.
Ja, haben sie, als Eintrag im übergeordneten Verzeichnis – wie alle Dateien (um sie "auffinden" zu können) – sind aber eine Ansammlung von z.B. 4096 Bytes, die "in spezieller Kodierung" Einträge für wiederum weitere Dateien/Verzeichnisse beinhaltet. Ich würde sie mit dem Katalog einer Bücherei vergleichen. So ein Katalog kann zwar in Buchform vorliegen, ist aber kein Buch im gewöhnlichen/regulären Sinn.
Ich habe schon 5 Euro auf der Straße gefunden, die ich nicht gesucht habe.
find findet aber nichts ohne vorausgehende Suche oder? OK Wortklauberei ☺ Im Supermarkt finde ich die zufällig heute angebotenen Pfifferlinge nur, wenn ich gezielt da reingehe und nach Gemüse suche.
Ich kann meine Mutter suchen ohne sie aufzusuchen und aufsuchen, ohne sie zu suchen.
Ah, ich verstehe, an diese Bedeutung von "aufsuchen" hatte ich nicht so direkt gedacht. Aus meinem (rheinischen) Sprachgefühl heraus könnte man aber durchaus ein Buch aufsuchen, um dann zu prüfen, ob es einem Suchkriterium wie z.B. Größe entspricht, so wie find es eben mit Dateien macht. Noch sehr viel schlechter wäre "... die auf gleiche Art eingetragen sind", was soll denn das heißen (rhetorische Frage)?
Eingetragen im Dateisystem! Mir ging es darum, ergänzend zu erläutern, warum in unixoiden Systemen "alles" als eine Datei betrachtet/behandelt werden kann, eben weil "alles" "auf gleiche Art im Dateisystem eingetragen ist" ("verzeichnet" ginge auch). In einem Büchereikatalog können neben regulären Büchern auch CD's und weitere Kataloge "eingetragen" sein. Ich kann sie nur "nach gleichen Kriterien finden", wenn sie auf "gleiche Art eingetragen" sind, und im Normalfall finde ich sie nicht zufällig, sondern nur wenn ich danach suche. Die Formulierung "nach gleichen Kriterien finden" stößt mir auf, weil Du z.B. Deine 5 Euro einfach nur gefunden hast, aber nicht "nach einem Kriterium". Ich meine, man kann "nach einem Kriterium" nur suchen, aber nicht finden ... bzw. "mittels" 😉 Im ersten Satz des Artikels steht: "find ist ein Kommandozeilenprogramm für die Dateisuche." Es sucht nach Dateien mittels Kriterien. EDIT: Und genau genommen werden nur Dateinamen gesucht, bzgl. deren Eigenschaften und Attributen gefiltert und ausgegeben, die Dateien selbst, also die Blocke mit den Bytes (=Dateiinhalt), werden weder gesucht noch ausgewertet, außer eben die von Verzeichnissen, um rekursiv weitersuchen zu können. Sollte ich mich irgendwo geirrt haben, kann sein, bin ja auch nur ein Informatiker als Mensch verkleidet. Deshalb würde ich gerne so schreiben (alles in [] ist jeweils fakultativ; | = alternativ): Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch z.B. Verzeichnisse Dateien [(mit speziell[ kodiert]em Inhalt)] sind [, und mittels gleicher Methoden und Kriterien [auf]gesucht werden können][, und|weil sie auf gleiche Art im Dateisystem verzeichnet sind]. (Man sucht sie "auf", wenn man damit was machen will, z.B. nach Kriterien filtern; man sucht sie, wenn man nur wissen will, wo sie sind. Beide Intentionen erfüllt find .) EDIT: ("aufgesucht" passt m.E. auch besser auf den allgemeinen Fall, auf den der zitierte Spruch doch sicher münzt, also das Lesen, Be- und Verarbeiten von Dateien, wofür sie aufgesucht werden müssen, mit welcher Methode auch immer, z.B. durch direkte Pfadangabe oder inode. Suchen mittels find ist da nur eine von vielen Möglichkeiten, das System in dem Sinne zu nutzen.)
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb: Hm, hätte nicht gedacht, dass es so schwierig ist, beidseitig zufriedenstellende Formulierungen zu finden. Liegt vielleicht an unterschiedlichem Sprachgebrauch in Ost und West
Meinst Du links- und rechtsrheinisch?
user_unknown schrieb: UlfZibis schrieb: Ich meinte, dass "normale Dateien" eine Ansammlung von Bytes beinhalten, die je nach Kodierung mit entsprechenden Programmen gelesen und bearbeitet werden können, während diese Bytes bei Verzeichnissen als Liste mit Verweisen zu weiteren Dateisystemobjekten interpretiert werden.
So kann man nicht vergleichen. Bei dem einen zählst Du 3 Eigenschaften auf, und wendest Dich dem anderen zu, ohne zu prüfen, ob die Eigenschaften da auch vorhanden sind, sondern wendest Dich einfach anderen Kriterien zu, die Du wiederum bei den ersten gar nicht ausgeschlossen hast.
Verstehe nicht von welchen 3 Eigenschaften Du sprichst und auch sonst nur Bahnhof. 🙄
Dateien enthalten Bytes diese unterliegen einer Kodierung, mit der bestimmte Programme etwas anfangen können oder nicht
Ordner enthalten auch Bytes. Die sind auch codiert. Programme, die damit etwas anfangen können sind Dateimanager, ls, find, ...
... während Verzeichnisse keine Ansammlung von Bytes beinhalten?
Doch, das schrieb ich doch mit "... während diese Bytes bei Verzeichnissen ..." Nicht kodiert sind?
Doch auch, werden aber "speziell" interpretiert, sind also nicht mit einem Anwendungsprogramm wie z.B. Texteditor, LibreOffice, GIMP etc. les- und bearbeitbar, sind halt Daten über Verweise zu weiteren Dateien, also keine "eigentlichen" Nutzdaten.
Mit Gänsefüßchen kannst Du ganz leicht Diskussionsorgien mit mir anzetteln. Speziell werden alle Dateien interpretiert - es gibt keine natürliche Interpretation einer Sequenz von Bytes. Wenn Du nicht speziell meinst, sondern was anderes, dann schreib es bitte hin. "Speziell" ist so ein Sich-um-den-richtigen-Ausdruck-Drücken, mit dem man an die Solidarität des Hörers oder Lesers appeliert, aber keine Sachverhalte beschreiben kann. Auch "eigentliche" Nutzdaten gegenüber eigentlichen Nutzdaten oder einfach nur Nutzdaten abzugrenzen fällt mir schwer. Je nach dem was ich mache sind Verzeichniseinträge natürlich auch wieder Nutzdaten. Zum Beispiel kann man mit dd ganze Partitionen in eine gewöhnliche Datei schreiben, da liegen dann die Bytes auch für einen Hexeditor zugänglich vor. Es soll aber ein find-Artikel werden, kein Essay zu "Unter Unix sagt man, alles ist eine Datei". Deswegen wollte ich es bei einer Bemerkung am Rande lassen. Wer mehr darüber wissen will muss es anderweitig recherchieren - hier hat er es aber mal gehört.
Man kann Verzeichnisse wie Dateien öffnen, lesen, kopieren.
Eben nicht so einfach, siehe oben. Und beim Kopieren wird nicht nur das Verzeichnis, sondern es werden auch sämtliche Dateien, auf die das Verzeichnis verweist, kopiert. Sie haben ein Erstelldatum, ein Datum der letzten Änderung, einen Eigentümer.
Ja, haben sie, als Eintrag im übergeordneten Verzeichnis – wie alle Dateien (um sie "auffinden" zu können) – sind aber eine Ansammlung von z.B. 4096 Bytes, die "in spezieller Kodierung" Einträge für wiederum weitere Dateien/Verzeichnisse beinhaltet. Ich würde sie mit dem Katalog einer Bücherei vergleichen. So ein Katalog kann zwar in Buchform vorliegen, ist aber kein Buch im gewöhnlichen/regulären Sinn.
Ja, aber das wollen wir nicht alles in den Findartikel schreiben. Verzeichnisse haben einen Eigentümer, 3 Datumseinträge, ... - wie andere Dateien. Verzeichnisse sind in anderen Verzeichnissen, wie andere Dateien. Verzeichnisse haben Namen, wie andere Dateien.
Ich habe schon 5 Euro auf der Straße gefunden, die ich nicht gesucht habe.
find findet aber nichts ohne vorausgehende Suche oder? OK Wortklauberei ☺ Im Supermarkt finde ich die zufällig heute angebotenen Pfifferlinge nur, wenn ich gezielt da reingehe und nach Gemüse suche.
Ich kann meine Mutter suchen ohne sie aufzusuchen und aufsuchen, ohne sie zu suchen.
Ah, ich verstehe, an diese Bedeutung von "aufsuchen" hatte ich nicht so direkt gedacht. Aus meinem (rheinischen) Sprachgefühl heraus könnte man aber durchaus ein Buch aufsuchen, um dann zu prüfen, ob es einem Suchkriterium wie z.B. Größe entspricht, so wie find es eben mit Dateien macht. Noch sehr viel schlechter wäre "... die auf gleiche Art eingetragen sind", was soll denn das heißen (rhetorische Frage)?
Eingetragen im Dateisystem! Mir ging es darum, ergänzend zu erläutern, warum in unixoiden Systemen "alles" als eine Datei betrachtet/behandelt werden kann, eben weil "alles" "auf gleiche Art im Dateisystem eingetragen ist" ("verzeichnet" ginge auch).
Dateisysteme zu erklären ist aber außerhalb des Scopes des Artikels. Ohne dass man vorher von Einträgen geredet hat ist "eingetragen sind" hier überraschend - wo eingetragen? Es interessiert wohl auch die meisten Leute wenig, so lange es funktioniert. Und dass das Finden hier eine Suche vorraussetzt versteht sich ja durch den Kontext von selbst. "Ich habe nach Dateien mit dem Namen "sik" gesucht und mit diesem Kriterium mehrere gefunden. Auf der anderen Partition habe ich mit dem gleichen Kriterium nichts gefunden." (Obwohl ich mit den gl. Kriterien gesucht habe.) Also mit den gleichen Kriterien gefunden, nicht nach den gleichen Kriterien gefunden? Kriterien sind hier Alter, Größe, Name usw.
Da könntest Du Recht haben.
In einem Büchereikatalog können neben regulären Büchern auch CD's und weitere Kataloge "eingetragen" sein. Ich kann sie nur "nach gleichen Kriterien finden", wenn sie auf "gleiche Art eingetragen" sind, und im Normalfall finde ich sie nicht zufällig, sondern nur wenn ich danach suche. Die Formulierung "nach gleichen Kriterien finden" stößt mir auf, weil Du z.B. Deine 5 Euro einfach nur gefunden hast,
Das war ja nur eine Randbemerkung.
aber nicht "nach einem Kriterium". Ich meine, man kann "nach einem Kriterium" nur suchen, aber nicht finden ... bzw. "mittels" 😉 Im ersten Satz des Artikels steht: "find ist ein Kommandozeilenprogramm für die Dateisuche." Es sucht nach Dateien mittels Kriterien.
In Wahrheit wollen wir aber schon meist finden. ☺ Gut - man kann eine Datei löschen, und mit find prüfen, dass man sie nicht mehr finden kann.
Sollte ich mich irgendwo geirrt haben, kann sein, bin ja auch nur ein Informatiker als Mensch verkleidet.
Sind wir das nicht alle?
Deshalb würde ich gerne so schreiben (alles in [] ist jeweils fakultativ; | = alternativ): Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch z.B. Verzeichnisse Dateien [(mit speziell[ kodiert]em Inhalt)] sind [, und mittels gleicher Methoden und Kriterien [auf]gesucht werden können][, und|weil sie auf gleiche Art im Dateisystem verzeichnet sind]. (Man sucht sie "auf", wenn man damit was machen will, z.B. nach Kriterien filtern; man sucht sie, wenn man nur wissen will, wo sie sind. Beide Intentionen erfüllt find .)
So sehe ich das auch. find -exec ... sucht die Datei oft auf, aber man nutzt nicht immer -exec. Also, weil man es nicht gut lesen kann mit all den Klammern und nicht klar wird, ob die Klammern irgendwie miteinander korrelieren picke ich mir eine Lesart raus: Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch (z.B.) Verzeichnisse Dateien sind und mittels gleicher Methoden und Kriterien gesucht werden können, weil sie auf gleiche Art im Dateisystem verzeichnet sind.
Mein Vorschlag mit minimalinvasiver Korrektur:
In der Kürze liegt die Würze (wie der sprachliche Moselfranke sagt). ☺
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Meinst Du links- und rechtsrheinisch?
Linksrheinisch. Berlin habe ich mir erlaubt rechtsrheinisch zu kartieren.
Ordner enthalten auch Bytes. Die sind auch codiert. Programme, die damit etwas anfangen können sind Dateimanager, ls, find, ...
Aber auch die lesen nicht einfach die Bytes der Ordner"datei" und interpretieren sie dann, sondern bemühen die dafür vorgesehenen Betriebssystem-Aufrufe.
Speziell werden alle Dateien interpretiert
... aber erst nachdem sie vom Betriebssystem roh an das jeweilige Programm weitergegeben wurden, während die Bytes in den Datenblöcken eines Verzeichnisses schon vom Betriebssystem selbst interpretiert werden - genau das ist das speziell spezielle daran.
"Speziell" ist so ein Sich-um-den-richtigen-Ausdruck-Drücken, mit dem man an die Solidarität des Hörers oder Lesers appeliert, aber keine Sachverhalte beschreiben kann.
Interessante Philosophie 👍
Zum Beispiel kann man mit dd ganze Partitionen in eine gewöhnliche Datei schreiben, da liegen dann die Bytes auch für einen Hexeditor zugänglich vor.
Dann habe ich aber keine Dateien mehr. Erst durch die strukturierte Interpretation des Betriebssystems werden die Roh-Bytes aus einer Partition zu einer unixoiden Datei, um deren Betrachtung es hier geht.
Wer mehr darüber wissen will muss es anderweitig recherchieren - hier hat er es aber mal gehört.
Zustimmung. Genau so hatte ich das auch bzgl. der Verwendung von "Namenstrenner" gemeint.
Ja, aber das wollen wir nicht alles in den Findartikel schreiben.
Gekauft, aber wenn wir schon den betreffenden Spruch im find -Artikel erläutern wollen, wäre ich dafür, dies gerne abgekürzt, aber dennoch präzise zu tun, solange das nicht mehr als 2..3 Worten mehr kostet. Verzeichnisse haben einen Eigentümer, 3 Datumseinträge, ... - wie andere Dateien. Verzeichnisse sind in anderen Verzeichnissen, wie andere Dateien. Verzeichnisse haben Namen, wie andere Dateien.
... und nicht nur Verzeichnisse, sondern auch alle anderen äquivalent verzeichneten Objekte.
Dateisysteme zu erklären ist aber außerhalb des Scopes des Artikels.
Gekauft, aber was spricht dagegen, die korrekten Begrifflichkeiten derer dennoch zu verwenden? Wie Du schon schriebst: "Wer mehr darüber wissen will muss es anderweitig recherchieren - hier hat er es aber mal gehört."
Ohne dass man vorher von Einträgen geredet hat ist "eingetragen sind" hier überraschend - wo eingetragen?
Ich fände es überraschend, wenn find Dinge finden würde, nicht nicht irgendwo - hier im Dateisystem - eingetragen sind.
Und dass das Finden hier eine Suche vorraussetzt versteht sich ja durch den Kontext von selbst.
Und dass das Suchen durch die Aussicht auf einen Fund motiviert ist, versteht sich durch den Kontext genauso von selbst.
"Ich habe nach Dateien mit dem Namen "sik" gesucht und mit diesem Kriterium mehrere gefunden. Auf der anderen Partition habe ich mit dem gleichen Kriterium nichts gefunden." (Obwohl ich mit den gl. Kriterien gesucht habe.)
Genau! Gefunden werden sie nur, wenn sie auch existieren. Deshalb stimmt der Satz "find sucht ..." immer und "find findet ..." nur manchmal.
Also mit den gleichen Kriterien gefunden, nicht nach den gleichen Kriterien gefunden? Kriterien sind hier Alter, Größe, Name usw.
Da könntest Du Recht haben.
Wir nähern uns, fein! Dennoch gebe ich zu bedenken: "Ich suche Oliven mittels geeigneten Kriterien im Schrank, und finde dann welche mit Stein.
(Man sucht sie "auf", wenn man damit was machen will, z.B. nach Kriterien filtern; man sucht sie, wenn man nur wissen will, wo sie sind. Beide Intentionen erfüllt find .)
So sehe ich das auch. find -exec ... sucht die Datei oft auf, aber man nutzt nicht immer -exec.
Auch ohne -exec muss man die Datei, bzw. deren Namen und Eigenschaften erst aufsuchen, um sie dann nach Kriterien filtern zu können.
... ob die Klammern irgendwie miteinander korrelieren
Na klar doch, eine öffnende Klammer korreliert immer mit einer schließenden.
Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch (z.B.) Verzeichnisse Dateien sind und mittels gleicher Methoden und Kriterien gesucht werden können, weil sie auf gleiche Art im Dateisystem verzeichnet sind.
Da der Spruch diese Tatsache nicht nur bzgl. Verzeichnissen beschreibt, sondern auch bzgl. anderen Objekten, fügte ich der Präzision wegen "(z.B.)" dazu, zumal es nur 6 zusätzliche Zeichen kostet.
Als Alternative war noch zu verstehen:
Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch (z.B.) Verzeichnisse Dateien sind, weil sie auf gleiche Art im Dateisystem verzeichnet sind. (diese Erklärung ist allgemeingültiger und ist nicht nur auf Thematik der Suche/des Findens mittels find reduziert, dennoch ergibt sich daraus der für find relevante Kontext.)
Mein Vorschlag mit minimalinvasiver Korrektur:
Wenn schon wegkürzen, dann würde ich die Erwähnung der "gleichen Methoden" den "gleichen Kriterien" bevorzugen, denn letztere sind für's Finden nicht immer notwendig.
In der Kürze liegt die Würze (wie der sprachliche Moselfranke sagt). ☺
Oha, jetzt wird's gefährlich, ich bin nämlich in Trier aufgewachsen. "aufgesucht" passt m.E. auch besser auf den allgemeinen Fall, auf den der zitierte Spruch doch sicher münzt, also das Lesen, Be- und Verarbeiten von Dateien, wofür sie aufgesucht werden müssen, mit welcher Methode auch immer, z.B. durch direkte Angabe von Pfad oder inode. Suchen mittels find ist da nur eine von vielen Möglichkeiten, das System in dem Sinne zu nutzen.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb:
Wer mehr darüber wissen will muss es anderweitig recherchieren - hier hat er es aber mal gehört.
Zustimmung. Genau so hatte ich das auch bzgl. der Verwendung von "Namenstrenner" gemeint.
Verstehe ich nicht. Meinst Du, jemand der länger und intensiver Linux nutzt wird früher oder später auf den Begriff Namenstrenner stoßen? Ich finde den Begriff befremdlich, bin also offenbar selten drauf gestoßen. Außerdem wird er ja, wie ich zeigen konnte, gar nicht benötigt. Das eigentliche Kriterium von -path ist, dass man nach Verzeichnisnamensmustern suchen kann.
Ja, aber das wollen wir nicht alles in den Findartikel schreiben.
Gekauft, aber wenn wir schon den betreffenden Spruch im find -Artikel erläutern wollen, wäre ich dafür, dies gerne abgekürzt, aber dennoch präzise zu tun, solange das nicht mehr als 2..3 Worten mehr kostet.
Kostet es aber wohl, wenn man nicht zu wolkigen Ausdrücken wie spezielle Datei greifen will, die auch nichts erklären.
Ohne dass man vorher von Einträgen geredet hat ist "eingetragen sind" hier überraschend - wo eingetragen?
Ich fände es überraschend, wenn find Dinge finden würde, nicht nicht irgendwo - hier im Dateisystem - eingetragen sind.
Ein Großteil der User, die sich noch nicht näher mit der Implementierung von Dateisystemen befasst haben, aber eher nicht.
Und dass das Finden hier eine Suche vorraussetzt versteht sich ja durch den Kontext von selbst.
Und dass das Suchen durch die Aussicht auf einen Fund motiviert ist, versteht sich durch den Kontext genauso von selbst.
"Ich habe nach Dateien mit dem Namen "sik" gesucht und mit diesem Kriterium mehrere gefunden. Auf der anderen Partition habe ich mit dem gleichen Kriterium nichts gefunden." (Obwohl ich mit den gl. Kriterien gesucht habe.)
Genau! Gefunden werden sie nur, wenn sie auch existieren. Deshalb stimmt der Satz "find sucht ..." immer und "find findet ..." nur manchmal.
Der Satz steht aber nicht zur Diskussion.
Also mit den gleichen Kriterien gefunden, nicht nach den gleichen Kriterien gefunden? Kriterien sind hier Alter, Größe, Name usw.
Da könntest Du Recht haben.
Wir nähern uns, fein! Dennoch gebe ich zu bedenken: "Ich suche Oliven mittels geeigneten Kriterien im Schrank, und finde dann welche mit Stein.
Geeignet sind vielleicht die Methoden. Mit welcher Methoder sucht der User eine Datei? Er bentutzt find mit den für sein Anliegen passenden Kriterien. find -color black -type stony.
(Man sucht sie "auf", wenn man damit was machen will, z.B. nach Kriterien filtern; man sucht sie, wenn man nur wissen will, wo sie sind. Beide Intentionen erfüllt find .)
So sehe ich das auch. find -exec ... sucht die Datei oft auf, aber man nutzt nicht immer -exec.
Auch ohne -exec muss man die Datei, bzw. deren Namen und Eigenschaften erst aufsuchen, um sie dann nach Kriterien filtern zu können.
Weiter oben hast Du noch viel Leidenschaft aufgewandt, um zu zeigen, dass Dateien primär in Einträgen gesucht werden, die nicht da sind, wo die Datei ist. Fazit: Die Datei wird manchmal aufgesucht, manchmal nicht. Aber gesucht wird sie von find eigentlich immer.
... ob die Klammern irgendwie miteinander korrelieren
Na klar doch, eine öffnende Klammer korreliert immer mit einer schließenden.
Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch (z.B.) Verzeichnisse Dateien sind und mittels gleicher Methoden und Kriterien gesucht werden können, weil sie auf gleiche Art im Dateisystem verzeichnet sind.
Da der Spruch diese Tatsache nicht nur bzgl. Verzeichnissen beschreibt, sondern auch bzgl. anderen Objekten, fügte ich der Präzision wegen "(z.B.)" dazu, zumal es nur 6 zusätzliche Zeichen kostet.
Als Alternative war noch zu verstehen:
Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch (z.B.) Verzeichnisse Dateien sind, weil sie auf gleiche Art im Dateisystem verzeichnet sind. (diese Erklärung ist allgemeingültiger und ist nicht nur auf Thematik der Suche/des Findens mittels find reduziert, dennoch ergibt sich daraus der für find relevante Kontext.)
Nun, dass nicht nur Verzeichnisse Dateien sind, das sagt bereits das auch. Dass es darüber hinaus diese Büchse der Pandorra gibt, mit Pipes und Sockets, das kann auch das z.B. nicht ausdrücken. Je deutlicher man da wird, desto eher muss man erklären was das ist. Ich wollte das nicht.
Mein Vorschlag mit minimalinvasiver Korrektur:
Wenn schon wegkürzen, dann würde ich die Erwähnung der "gleichen Methoden" den "gleichen Kriterien" bevorzugen, denn letztere sind für's Finden nicht immer notwendig.
Welche Methoden sind das denn? Dass man überhaupt find benutzt, und dass man optional Kriterien verwendet, die die Suche näher spezifizieren.
In der Kürze liegt die Würze (wie der sprachliche Moselfranke sagt). ☺
Oha, jetzt wird's gefährlich, ich bin nämlich in Trier aufgewachsen.
Mh, mh. Aber wahrscheinlich später. Ich kenn keinen Ulf aus Trier. Hab' in der An der Meerkatz gewohnt, und fahr gelegentlich hin, um meine Eltern zu besuchen.
"aufgesucht" passt m.E. auch besser auf den allgemeinen Fall, auf den der zitierte Spruch doch sicher münzt, also das Lesen, Be- und Verarbeiten von Dateien, wofür sie aufgesucht werden müssen, mit welcher Methode auch immer, z.B. durch direkte Angabe von Pfad oder inode. Suchen mittels find ist da nur eine von vielen Möglichkeiten, das System in dem Sinne zu nutzen.
Ich verstehe den Spruch so, dass es gerade eine Vielzahl ganz unterschiedlicher Probleme gibt, die mit einer Datei gelöst werden. Als augenfälligste Beispiele würde ich die Dateistruktur unter /proc bemühen, eine Datei wie /dev/null, /dev/random usw.
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29045
Wohnort: WW
|
Hallo, nochmal die Frage: Stand der Dinge? Das (geplante) Fertigstellungsdatum ist schon ein paar Tage her... Gruß, noisefloor
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Da bin ich nun wieder ... user_unknown schrieb: Meinst Du, jemand der länger und intensiver Linux nutzt wird früher oder später auf den Begriff Namenstrenner stoßen?
Ja, oder ihn bei Gefallen selbst verwenden, wenn es der Kontext erlaubt. Außerdem wird er ja, wie ich zeigen konnte, gar nicht benötigt.
Du meinst wohl das hier: Sucht man nach Verzeichnisnamen kommt man mit '-name' nicht weiter, da das nur den reinen Dateinamen berücksichtigt. Der Parameter '-path' erlaubt die Suche nach Pfadnamensteilen; mit Hilfe des Slashs '/' auch über Verzeichnisnamensgrenzen hinweg:
Du verwendest aber statt dessen "Slash" und zusätzlich "Verzeichnisnamensgrenzen", das ist auf jeden Fall länger. Und 2. lies den Satz mal laut jemandem vor (2 mal "Slash" hintereinander) 😲 und 3. warum nicht "Schrägstrich" auf Deutsch? Was ist denn an "...namensgrenzen" besser als an "Namenstrenner"? Der Begriff ist wiederum mir noch nicht über den Weg gelaufen, und für mich außerdem vieldeutig – darunter könnte auch die maximale Länge oder die Aufhebung der Begrenzung auf zulässige Zeichen verstanden werden. Du unterscheidest zwischen "Verzeichnisnamen" und "reinen Dateinamen", als ob die sich gegenseitig ausschließen. Das widerspricht dem "Alles ist eine Datei" und außerdem kann man mit -name sehr wohl nach Verzeichnisnamen und Teilen davon suchen, nur eben nicht als Teil eines Pfads.
Das eigentliche Kriterium von -path ist, dass man nach Verzeichnisnamensmustern suchen kann.
Nee eben nicht, sondern dass man nach/mittels Pfadmustern suchen kann.
Kostet es aber wohl, wenn man nicht zu wolkigen Ausdrücken wie spezielle Datei greifen will, die auch nichts erklären.
Können wir, wie ich schon sagte, gerne weg lassen diese Wolke.
Ich fände es überraschend, wenn find Dinge finden würde, nicht nicht irgendwo - hier im Dateisystem - eingetragen sind.
Ein Großteil der User, die sich noch nicht näher mit der Implementierung von Dateisystemen befasst haben, aber eher nicht.
Jetzt treibst Du's aber auf die Spitze 😀 Ich würde mich schon wundern, wenn find den Schlüssel finden würde, den ich gestern verloren habe.
Also mit den gleichen Kriterien gefunden, nicht nach den gleichen Kriterien gefunden? Kriterien sind hier Alter, Größe, Name usw.
Da könntest Du Recht haben.
Wir nähern uns, fein! Dennoch gebe ich zu bedenken: "Ich suche Oliven mittels geeigneten Kriterien im Schrank, und finde dann welche mit Stein.
Also die Kriterien mittels derer ich suche könnten dann z.B. sein: Glas mit grünem Deckel oder Aufschrift: "Oliven". Ob ich dann welche mit oder ohne Stein finde, wird vom Kriterium nicht bestimmt, genauso wie Du einen Weg nach Hause findest, mit oder ohne Euro auf dem Boden. Antworte mal als Gärtner, dass Du den Garten mit Hut bearbeiten/behandeln wirst. Geeignet sind vielleicht die Methoden. Mit welcher Methoder sucht der User eine Datei? Er bentutzt find mit den für sein Anliegen passenden Kriterien. find -color black -type stony.
Die Gültigkeit des Spruchs ist ja nicht auf find beschränkt. Er ist ja deshalb allgemeingültig, weil er für alle möglichen Methoden gilt, mit denen man Dateien aufsuchen und finden kann und die sich letztlich alle gleicher übergeordneter Methoden (=Betriebssystemaufrufe) bedienen, denen eben allen gleich ist, dass sie für die Identifikation eine mit dem Namenstrenner '/' strukturierte, sonst aber allgemeine Zeichenkette verwenden. Ein Gegenbeispiel wären z.B. Datenbanken, wo die Daten mittels anderer Methoden aufgesucht werden müssen.
(Man sucht sie "auf", wenn man damit was machen will, z.B. nach Kriterien filtern; man sucht sie, wenn man nur wissen will, wo sie sind. Beide Intentionen erfüllt find .)
So sehe ich das auch. find -exec ... sucht die Datei oft auf, aber man nutzt nicht immer -exec.
Auch ohne -exec muss man die Datei, bzw. deren Namen und Eigenschaften erst aufsuchen, um sie dann nach Kriterien filtern zu können.
Weiter oben hast Du noch viel Leidenschaft aufgewandt, um zu zeigen, dass Dateien primär in Einträgen gesucht werden, die nicht da sind, wo die Datei ist.
Nein, sondern dass Dateinamen in (Verzeichnis-)Einträgen gesucht werden. Aber gesucht wird sie von find eigentlich immer.
Im Fall von find schon, nicht aber im Fall von allen möglichen anderen Methoden, auf die sich der Spruch ja auch bezieht, wie z.B. bei direkter Pfadangabe in einem Betriebssystemaufruf oder einem Befehl wie delete . find sucht also den Dateinamens- und Eigenschafteneintrag auf um ihn entsprechend der gegebenen Kriterien zu untersuchen, genau genommen nie die Datei selbst.
Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch (z.B.) Verzeichnisse Dateien sind und mittels gleicher Methoden und Kriterien gesucht werden können, weil sie auf gleiche Art im Dateisystem verzeichnet sind.
Da der Spruch diese Tatsache nicht nur bzgl. Verzeichnissen beschreibt, sondern auch bzgl. anderen Objekten, fügte ich der Präzision wegen "(z.B.)" dazu, zumal es nur 6 zusätzliche Zeichen kostet.
Der Leser könnte sonst auch zu dem Verständnis kommen, dass sonst nur Objekte gemeint sind, die Platz auf einem Datenträger verwenden, was Sockets ja nicht tun. Als Alternative war noch zu verstehen:
Auf unixoiden Systemen beschreibt der Spruch "Alles ist eine Datei" die Tatsache, dass auch (z.B.) Verzeichnisse Dateien sind, weil sie auf gleiche Art im Dateisystem verzeichnet sind. (diese Erklärung ist allgemeingültiger und ist nicht nur auf Thematik der Suche/des Findens mittels find reduziert, dennoch ergibt sich daraus der für find relevante Kontext.)
Nun, dass nicht nur Verzeichnisse Dateien sind, das sagt bereits das auch. Dass es darüber hinaus diese Büchse der Pandorra gibt, mit Pipes und Sockets, das kann auch das z.B. nicht ausdrücken. Je deutlicher man da wird, desto eher muss man erklären was das ist. Ich wollte das nicht.
Verstehe, was Du meinst. Ohne das "(z.B.)" wirkt es für mich aber so ausschliesslich, denn der Spruch "Alles ist eine Datei" beschreibt, dass auch vieles andere wie eine Datei behandelt, z.B. deren Eigenschaftseintrag oder sie selbst aufgesucht, wird, und eben nicht nur auch Verzeichnisse. find findet deshalb eben jede Art von Objekten, die im Dateisystem eingetragen sind, nicht mehr, aber auch nicht weniger.
... und jemand der genau wissen will, was im Dateisystem alles als Datei gilt, wird m.E. schon damit zufrieden sein, genaueres dazu im Wiki-Artikel über Dateisysteme suchen zu müssen. Der Zusatz "(z.B.)" soll aber für mich nicht "kriegsentscheidend" sein.
Mein Vorschlag mit minimalinvasiver Korrektur:
Wenn schon wegkürzen, dann würde ich die Erwähnung der "gleichen Methoden" den "gleichen Kriterien" bevorzugen, denn letztere sind für's Finden nicht immer notwendig.
Welche Methoden sind das denn?
Siehe oben. Also unter anderem Identifizierung mit durch Namenstrenner strukturierten Zeichenketten. Dass man überhaupt find benutzt, und dass man optional Kriterien verwendet, die die Suche näher spezifizieren.
Genau das!
In der Kürze liegt die Würze (wie der sprachliche Moselfranke sagt). ☺
Oha, jetzt wird's gefährlich, ich bin nämlich in Trier aufgewachsen.
Mh, mh. Aber wahrscheinlich später. Ich kenn keinen Ulf aus Trier. Hab' in der An der Meerkatz gewohnt, und fahr gelegentlich hin, um meine Eltern zu besuchen.
Dann bist Du aber schon ein alter Knochen, müsste dann vor 1960 gewesen sein. Ich auf der Hill, also nicht ganz so zentral und ich war auf dem MPG. Trier ist eine Großstadt - ha ha - da ist die Wahrscheinlichkeit, einen seltenen Ulf zu kennen nicht zwingend, eher schon den ein oder anderen user_unknown. "Om Duumstaan simmer rumgerutscht, et war nit immer ginstisch. De Kaap verlor, de Bux zerriss, plutrinstisch." Wärest Du damit einverstanden, dass ich die Baustelle erstmal mehr oder weniger in meinem Sinne vorarbeite, und Du sie dann nachkorrigierst?
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Du verwendest aber statt dessen "Slash" und zusätzlich "Verzeichnisnamensgrenzen", das ist auf jeden Fall länger. Und 2. lies den Satz mal laut jemandem vor (2 mal "Slash" hintereinander)  und 3. warum nicht "Schrägstrich" auf Deutsch?
Deswegen 2x hintereinander. Oft wird, meiner Erfahrung nach öfter, auch in deutschsprachigen Foren, vom Slash geredet, als vom Schrängstrich, und zur Erläuterung setzte ich den visuellen Schrägstrich dahinter.
Was ist denn an "...namensgrenzen" besser als an "Namenstrenner"?
Der Fall auf den Du hinauswillst, dass man über die Namensgrenze hinweg sucht, ist der, bei dem der Slash als Namensverbinder, nicht als -trenner fungiert.
Du unterscheidest zwischen "Verzeichnisnamen" und "reinen Dateinamen", als ob die sich gegenseitig ausschließen. Das widerspricht dem "Alles ist eine Datei" und außerdem kann man mit -name sehr wohl nach Verzeichnisnamen und Teilen davon suchen, nur eben nicht als Teil eines Pfads.
| find -name img/03.jpg
find: Warnung: Unix Dateinamen enthalten gewöhnlich keine Schrägstriche (anders als Pfadbezeichnungen). Deshalb wird '-name "img/03.jpg"' wahrscheinlich immer "Falsch" auf diesem System ergeben. Möglicherweise sind '-wholename' oder '-samefile' bessere Tests. Alternativ kann auch GNU grep verwendet werden: 'find ... -print0 | grep -FzZ "img/03.jpg"'.
|
Ich kann nach -name img suchen, was ein Verzeichnisname ist.
Das eigentliche Kriterium von -path ist, dass man nach Verzeichnisnamensmustern suchen kann.
Nee eben nicht, sondern dass man nach/mittels Pfadmustern suchen kann.
Worin siehst Du da den Unterschied?
Ich fände es überraschend, wenn find Dinge finden würde, nicht nicht irgendwo - hier im Dateisystem - eingetragen sind.
Ein Großteil der User, die sich noch nicht näher mit der Implementierung von Dateisystemen befasst haben, aber eher nicht.
Jetzt treibst Du's aber auf die Spitze 😀 Ich würde mich schon wundern, wenn find den Schlüssel finden würde, den ich gestern verloren habe.
Ich meinte mehr so Sachen /dev/null oder /proc/cpuinfo.
(Man sucht sie "auf", wenn man damit was machen will, z.B. nach Kriterien filtern; man sucht sie, wenn man nur wissen will, wo sie sind. Beide Intentionen erfüllt find .)
So sehe ich das auch. find -exec ... sucht die Datei oft auf, aber man nutzt nicht immer -exec.
Auch ohne -exec muss man die Datei, bzw. deren Namen und Eigenschaften erst aufsuchen, um sie dann nach Kriterien filtern zu können.
Weiter oben hast Du noch viel Leidenschaft aufgewandt, um zu zeigen, dass Dateien primär in Einträgen gesucht werden, die nicht da sind, wo die Datei ist.
Nein, sondern dass Dateinamen in (Verzeichnis-)Einträgen gesucht werden. Aber gesucht wird sie von find eigentlich immer.
Im Fall von find schon, nicht aber im Fall von allen möglichen anderen Methoden, auf die sich der Spruch ja auch bezieht, wie z.B. bei direkter Pfadangabe in einem Betriebssystemaufruf oder einem Befehl wie delete . find sucht also den Dateinamens- und Eigenschafteneintrag auf um ihn entsprechend der gegebenen Kriterien zu untersuchen, genau genommen nie die Datei selbst.
Wir kamen von dem Satz: 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.
Es geht um Verzeichnisse und Dateien und um die Suche mittels find. Es geht nicht darum, dass Dateieinträge im Dateisystem aufgesucht werden, auch wenn das im Hintergrund immer passiert. Die Benutzung der Suche mit find soll dem Leser vermittelt werden, die zugrundeliegende Technik nur soweit es unabdingbar ist. Dass eine Datei umbenannt wird ist für den User eine Operation auf der Datei. Wenn die Datei dabei nicht auf eine andere Partition verschoben wird, wird die Datei gar nicht angefasst, sondern nur ihr Eintrag. Das ist für den User manchmal nützlich zu wissen aber die meisten User dürften eine Vorstellung vom Dateisystem haben, bei dem die Metainformationen und die Daten eine Einheit bilden. Solange alles rund läuft arbeite ich auch mit diesem einfachen, aber anschaulichen Modell. Wenn ich mit find arbeite suche ich meist eine Datei, aber oft suche ich die Datei dann nicht auf.
Welche Methoden sind das denn?
Siehe oben. Also unter anderem Identifizierung mit durch Namenstrenner strukturierten Zeichenketten.
Dass der Pfad auf ein Zeichenkettenmuster passt ist ja ein Kriterium.
In der Kürze liegt die Würze (wie der sprachliche Moselfranke sagt). ☺
Oha, jetzt wird's gefährlich, ich bin nämlich in Trier aufgewachsen.
Mh, mh. Aber wahrscheinlich später. Ich kenn keinen Ulf aus Trier. Hab' in der An der Meerkatz gewohnt, und fahr gelegentlich hin, um meine Eltern zu besuchen.
Dann bist Du aber schon ein alter Knochen, müsste dann vor 1960 gewesen sein. Ich auf der Hill, also nicht ganz so zentral und ich war auf dem MPG. Trier ist eine Großstadt - ha ha - da ist die Wahrscheinlichkeit, einen seltenen Ulf zu kennen nicht zwingend, eher schon den ein oder anderen user_unknown. "Om Duumstaan simmer rumgerutscht, et war nit immer ginstisch. De Kaap verlor, de Bux zerriss, plutrinstisch."
Dann musst Du der alte Knochen sein. Ich bin bis '83 in Trier aufgewachsen - danach war Schluss mit aufwachsen und mit Trier. ☺
Wärest Du damit einverstanden, dass ich die Baustelle erstmal mehr oder weniger in meinem Sinne vorarbeite, und Du sie dann nachkorrigierst?
Ich finde es schwierig nach ein paar Wochen wieder in die Streitpunkte zurückzufinden. Daher wäre ich vor allem froh, wenn wir bald ein Ende finden. ☺
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
user_unknown schrieb: Deswegen 2x hintereinander.
Als Nachhilfe für die, die noch nicht mal Denglisch können, geschweige denn Englisch? Oft wird, meiner Erfahrung nach öfter, auch in deutschsprachigen Foren, vom Slash geredet, als vom Schrängstrich, und zur Erläuterung setzte ich den visuellen Schrägstrich dahinter.
Betrifft das nicht eher den "backslash", weil dessen deutsche Übersetzung so ein Zungenbrecher ist? Es wird auch immer öfter "file", "paper", "outdoor", … statt "Datei", "Papier" "draussen", … verwendet. Ich finde, dass man sich schlechten Gewohnheiten durchaus entziehen darf. Wie Du siehst, verwendet sogar Ubuntu "Schrägstrich" in Deiner zitierten Fehlermeldung. Weil das ursprüngliche "Zeichen '/'" fast genauso redundant ist wie "Schrägstrich '/'", wäre ich für das komplette Weglassen, wenn Du den deutschsprachigen Ubuntu-Benutzern "Namenstrenner" nicht zumuten möchtest. Schöner klingt es im Deutschen aber mit einer vorangestellten treffenden Bezeichnung, weshalb es z.B. auch heißt: "Diesen Plan hat der Herr Mayer entworfen."
Der Fall auf den Du hinauswillst, dass man über die Namensgrenze hinweg sucht, ist der, bei dem der Slash als Namensverbinder, nicht als -trenner fungiert.
Eine Grenze bzw. die Markierung einer solchen hat bei Dir also etwas Verbindendes, so ähnlich wie die Mauer in Berlin mal. Ich verstehe Deine "alternative" Sichtweise, aber der Logik nach wäre das Leerzeichen dann ein "Wortverbinder" 😀 . Pfadverbinder würde ich evtl. noch durchgehen lassen, denn '/' verbindet Namen zu einer Pfadbezeichnung, im Englischen heißt es aber "name separator". Einen "path separator" gibt's da auch, das ist unter UNIX der ':' und unter Windows das ';'.
Du unterscheidest zwischen "Verzeichnisnamen" und "reinen Dateinamen", als ob die sich gegenseitig ausschließen. Das widerspricht dem "Alles ist eine Datei" und außerdem kann man mit -name sehr wohl nach Verzeichnisnamen und Teilen davon suchen, nur eben nicht als Teil eines Pfads.
Ich kann nach -name img suchen, was ein Verzeichnisname ist.
Genau, ... Das eigentliche Kriterium von -path ist, dass man nach Verzeichnisnamensmustern suchen kann.
... und mit -name "*mg" sogar nach Verzeichnisnamensmustern. Deshalb kann das nicht das "eigentliche Kriterium" von -path sein.
Nee eben nicht, sondern dass man nach/mittels Pfadmustern suchen kann.
Worin siehst Du da den Unterschied?
Mit einem Verzeichnisnamensmuster kann man nach Verzeichnisnamen suchen, die nach dem Spruch wiederum Dateinamen, also verallgemeinert "Namen" (-name ) sind, und beide kein '/' enthalten dürfen, während Pfad(bezeichnungs)muster das eben dürfen.
Ich fände es überraschend, wenn find Dinge finden würde, die nicht irgendwo - hier im Dateisystem - eingetragen sind.
Ein Großteil der User, die sich noch nicht näher mit der Implementierung von Dateisystemen befasst haben, aber eher nicht.
Jetzt treibst Du's aber auf die Spitze 😀 Ich würde mich schon wundern, wenn find den Schlüssel finden würde, den ich gestern verloren habe.
Ich meinte mehr so Sachen /dev/null oder /proc/cpuinfo.
Meinem Verständnis nach sind die doch auch im Dateisystem "eingetragen" (im Gegensatz von z.B. Einhängepunkten, die in der Datei fstab eingetragen sind).
(Man sucht sie "auf", wenn man damit was machen will, z.B. nach Kriterien filtern; man sucht sie, wenn man nur wissen will, wo sie sind. Beide Intentionen erfüllt find .)
So sehe ich das auch. find -exec ... sucht die Datei oft auf, aber man nutzt nicht immer -exec.
Auch ohne -exec muss man die Datei, bzw. deren Namen und Eigenschaften erst aufsuchen, um sie dann nach Kriterien filtern zu können.
Weiter oben hast Du noch viel Leidenschaft aufgewandt, um zu zeigen, dass Dateien primär in Einträgen gesucht werden, die nicht da sind, wo die Datei ist.
Nein, sondern dass Dateinamen in (Verzeichnis-)Einträgen gesucht werden. Aber gesucht wird sie von find eigentlich immer.
Im Fall von find schon, nicht aber im Fall von allen möglichen anderen Methoden, auf die sich der Spruch ja auch bezieht, wie z.B. bei direkter Pfadangabe in einem Betriebssystemaufruf oder einem Befehl wie delete . find sucht also den Dateinamens- und Eigenschafteneintrag auf um ihn entsprechend der gegebenen Kriterien zu untersuchen, genau genommen nie die Datei selbst.
Wir kamen von dem Satz: 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.
Es geht um Verzeichnisse und Dateien und um die Suche mittels find.
Ich würde sagen, in umgekehrter Reihenfolge.
In 1. Priorität geht es um find … sonst müsste der Artikel "Datei und Verzeichnissuche" heißen. Mit find kann man alles – nennen wir es Objekte – finden, was im Dateisystem verzeichnet ist. Weil diese Objekte alle mit der gleichen Methode, nämlich per Pfadbezeichnungen, adressiert werden, kann man so tun, als ob das alles Dateien sind, was mit dem Spruch eben zum Ausdruck gebracht werden soll. Der Spruch bezieht sich aber nicht speziell auf find , sondern auf alle Befehle, die dem Zugriff auf solche Objekte dienen, weshalb der den Spruch erläuternde Nebensatz m.E. genauso allgemein gehalten werden sollte, in dem "Verzeichnisse" als ein Beispiel von mehreren Möglichkeiten genannt werden kann. Das ist dann auch im korrekten Einklang mit dem seltenen Fall, dass find dem Benutzer mal was anderes als eine Datei oder ein Verzeichnis auflistet, ohne dass in diesem Artikel näher darauf hingewiesen werden muss, z.B. im Fall von find -name "*nul*" . Und da man im allgemeinen Fall, also eines beliebigen Befehls, auf den der Spruch zutrifft, mit dem/den Objekt(en) etwas machen will, finde ich dafür "Aufsuchen" passend. edit /home/otto/Datei hat nichts mit Suchen zu tun, eher mit Aufsuchen (zum Zweck des Editierens). Auch find muss sich des durch den Spruch umschriebenen Mechanismus des Aufsuchens – unter der Haube – bedienen, um seine Aufgabe des Findens zu erfüllen, steht damit nicht wirklich im Widerspruch zum nur Suchen aus äußerer Sicht und meistens ist ja dann auch das Aufsuchen eines der Suchergebnisse beabsichtigt. find liefert die dafür benötigten Pfadbezeichnungen. Erst danach (dem Spruch) geht es dann im Artikel wieder speziell um den Befehl find .
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.
Vielleicht ist im Kontext des Spruchs auch "zugreifen" weniger irritierend als "aufsuchen".
Es geht nicht darum, dass Dateieinträge im Dateisystem aufgesucht werden,
Für die korrekte Erläuterung des Spruchs meiner Ansicht nach schon. Für den nachfolgend beschriebenen Umgang mit find nicht unbedingt, weshalb ich ja auch den Zusatz "im Dateisystem" im Artikeltext nicht verwendet habe auch wenn das im Hintergrund immer passiert. Die Benutzung der Suche mit find soll dem Leser vermittelt werden, die zugrundeliegende Technik nur soweit es unabdingbar ist.
Zustimmung, der Einschub mit dem Spruch muss darauf aber nicht einschränkend inkorrekt formuliert sein.
Das ist für den User manchmal nützlich zu wissen aber die meisten User dürften eine Vorstellung vom Dateisystem haben, bei dem die Metainformationen und die Daten eine Einheit bilden.
Diese User dürften aber eher die Suchfunktion eines Dateibrowsers nutzen. Selbst ich gehörte bislang zu diesen. Den wenigen, die sich die Mühe machen, sich mit der komplizierten find -Syntax herumzuschlagen, traue ich dieses "Basiswissen" über Dateihaltung zu.
Solange alles rund läuft arbeite ich auch mit diesem einfachen, aber anschaulichen Modell. Wenn ich mit find arbeite suche ich meist eine Datei, aber oft suche ich die Datei dann nicht auf.
Ich auch, dazu brauche ich aber nicht die Hintergrundinfo, die mittels des Spruchs für Klarheit im Sonderfall sorgen soll. Und nur im Sonderfall wird man find bemühen, sonst eher die Suchfunktion eines Dateibrowsers.
Welche Methoden sind das denn?
Siehe oben. Also unter anderem Identifizierung mit durch Namenstrenner strukturierten Zeichenketten.
Dass der Pfad auf ein Zeichenkettenmuster passt ist ja ein Kriterium.
... dass man die für Dateien übliche Methode auch für das Aufsuchen anderer so adressierter Objekte benutzen kann.
Dann musst Du der alte Knochen sein. Ich bin bis '83 in Trier aufgewachsen - danach war Schluss mit aufwachsen und mit Trier. ☺
Ich musste '80 wegen der BW weg und '82 habe ich mich dann endgültig vom Acker gemacht, nach Aachen zum Studieren.
Wärest Du damit einverstanden, dass ich die Baustelle erstmal mehr oder weniger in meinem Sinne vorarbeite, und Du sie dann nachkorrigierst?
Ich finde es schwierig nach ein paar Wochen wieder in die Streitpunkte zurückzufinden. Daher wäre ich vor allem froh, wenn wir bald ein Ende finden. ☺
Verstehe, sorry dass ich es so hinziehen musste. Und deshalb ja mein Vorschlag.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
UlfZibis schrieb: Betrifft das nicht eher den "backslash", weil dessen deutsche Übersetzung so ein Zungenbrecher ist?
Beim Backslash spricht man vom Backslash, nicht vom Slash, wie Du performativ selbst schon gezeigt hast. ☺ Ein Zungenbrecher ist es nicht. Ich bin aber nicht mit dem Slash zwangsverheiratet und wäre bereit den zu verkaufen.
Da ich aber schon selbst zu den aggressiven Eindeutschern zähle muss ich ab und zu ein symbolisches Opfer bringen, um nicht als Dogmatiker durchschaut zu werden und der vorwärts geneigte Schrägstrich bot sich da an. Es wird auch immer öfter "file", "paper", "outdoor", … statt "Datei", "Papier" "draussen", … verwendet.
Paper steht meist für Text oder Aufsatz. Ich finde, dass man sich schlechten Gewohnheiten durchaus entziehen darf.
Da es keine schlechte Gewohnheit meinerseits ist, trifft mich das nicht. ☺ Wie Du siehst, verwendet sogar Ubuntu "Schrägstrich" in Deiner zitierten Fehlermeldung. Weil das ursprüngliche "Zeichen '/'" fast genauso redundant ist wie "Schrägstrich '/'", wäre ich für das komplette Weglassen, wenn Du den deutschsprachigen Ubuntu-Benutzern "Namenstrenner" nicht zumuten möchtest. Schöner klingt es im Deutschen aber mit einer vorangestellten treffenden Bezeichnung, weshalb es z.B. auch heißt: "Diesen Plan hat der Herr Mayer entworfen."
Ich fand das Wort nie schön, weiß aber auch nicht wie der piefige Schreibmaschinist der 80er das Divisionszeichen der Schreibmaschiene genannt hat. Wahrscheinlich, weil das Wort nicht so verbreitet ist, und zudem nicht eindeutig, weil der rückwärtsgewandte Bruder ja auch ein Schrägstrich ist. Divisionszeichen leider auch nicht, weil es da ja noch den Horizontalstrich durch den Doppelpunkt gibt, dessen UTF-Code ich jetzt nicht raussuche und der auf dem Ziffernblock auch oft so dargestellt wird, dann aber doch einen Slash erzeugt. ☺
Der Fall auf den Du hinauswillst, dass man über die Namensgrenze hinweg sucht, ist der, bei dem der Slash als Namensverbinder, nicht als -trenner fungiert.
Eine Grenze bzw. die Markierung einer solchen hat bei Dir also etwas Verbindendes, so ähnlich wie die Mauer in Berlin mal. Ich verstehe Deine "alternative" Sichtweise, aber der Logik nach wäre das Leerzeichen dann ein "Wortverbinder" 😀 .
Nehmen wir ls in /usr/bin. Usr und bin sind Verzeichnisnamen die per Slash zu einem Pfad verbunden sind, in der Tat. Usr und bin in /usr/local/bin dagegen sind nicht mit einem Slash verbunden. Und in der Tat waren BRD und DDR durch eine Grenze miteinander verbunden, während es BRD und Ungarn nicht sind.
Pfadverbinder würde ich evtl. noch durchgehen lassen, denn '/' verbindet Namen zu einer Pfadbezeichnung, im Englischen heißt es aber "name separator".
Engländer werden weithin überschätzt. ☺ Zumal bei denen das Leerzeichen als Wortverbinder fungiert, während wir im Deutschen dafür einen Bindestrich nehmen, wenn wir die Wörter nicht gleich fusionieren. Von mir aus nimm Trenner.
Einen "path separator" gibt's da auch, das ist unter UNIX der ':' und unter Windows das ';'.
Du unterscheidest zwischen "Verzeichnisnamen" und "reinen Dateinamen", als ob die sich gegenseitig ausschließen. Das widerspricht dem "Alles ist eine Datei" und außerdem kann man mit -name sehr wohl nach Verzeichnisnamen und Teilen davon suchen, nur eben nicht als Teil eines Pfads.
Man kann mit -name "bin" nach /usr/bin suchen, aber nicht mit -name "*r/b*". Mit -name kann man überhaupt nur Verzeichnisse mit diesem Namen suchen, nicht nach Dateien in Verzeichnissen dieses Namens.
Ich kann nach -name img suchen, was ein Verzeichnisname ist.
Genau, ... Das eigentliche Kriterium von -path ist, dass man nach Verzeichnisnamensmustern suchen kann.
... und mit -name "*mg" sogar nach Verzeichnisnamensmustern. Deshalb kann das nicht das "eigentliche Kriterium" von -path sein.
Nach Verzeichnisnamensmustern, in denen die Datei ist, nicht nur nach Verzeichnissen, die diesem Namensmuster entsprechen was bei -name der Fall ist, und die Suche über Verzeichnisnamensgrenzen hinweg ausschließt.
Nee eben nicht, sondern dass man nach/mittels Pfadmustern suchen kann.
Worin siehst Du da den Unterschied?
Mit einem Verzeichnisnamensmuster kann man nach Verzeichnisnamen suchen, die nach dem Spruch wiederum Dateinamen, also verallgemeinert "Namen" (-name ) sind, und beide kein '/' enthalten dürfen, während Pfad(bezeichnungs)muster das eben dürfen.
Hm. Klingt, wie das, was ich auch eben geschrieben habe.
Ich fände es überraschend, wenn find Dinge finden würde, die nicht irgendwo - hier im Dateisystem - eingetragen sind.
Ein Großteil der User, die sich noch nicht näher mit der Implementierung von Dateisystemen befasst haben, aber eher nicht.
Jetzt treibst Du's aber auf die Spitze 😀 Ich würde mich schon wundern, wenn find den Schlüssel finden würde, den ich gestern verloren habe.
Ich meinte mehr so Sachen /dev/null oder /proc/cpuinfo.
Meinem Verständnis nach sind die doch auch im Dateisystem "eingetragen" (im Gegensatz von z.B. Einhängepunkten, die in der Datei fstab eingetragen sind).
Ich schrieb vom Großteil der User, die eben nichts von separaten Einträgen im Dateisystem wissen.
(Man sucht sie "auf", wenn man damit was machen will, z.B. nach Kriterien filtern; man sucht sie, wenn man nur wissen will, wo sie sind. Beide Intentionen erfüllt find .)
(...) Im Fall von find schon, nicht aber im Fall von allen möglichen anderen Methoden, auf die sich der Spruch ja auch bezieht, wie z.B. bei direkter Pfadangabe in einem Betriebssystemaufruf oder einem Befehl wie delete . find sucht also den Dateinamens- und Eigenschafteneintrag auf um ihn entsprechend der gegebenen Kriterien zu untersuchen, genau genommen nie die Datei selbst.
Man sucht sie aber oft eben nicht auf, sondern informiert sich nur mit find.
Wir kamen von dem Satz: 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.
Es geht um Verzeichnisse und Dateien und um die Suche mittels find.
Ich würde sagen, in umgekehrter Reihenfolge.
(...)
Und da man im allgemeinen Fall, also eines beliebigen Befehls, auf den der Spruch zutrifft, mit dem/den Objekt(en) etwas machen will, finde ich dafür "Aufsuchen" passend. edit /home/otto/Datei hat nichts mit Suchen zu tun, eher mit Aufsuchen (zum Zweck des Editierens). Auch find muss sich des durch den Spruch umschriebenen Mechanismus des Aufsuchens – unter der Haube – bedienen, um seine Aufgabe des Findens zu erfüllen, steht damit nicht wirklich im Widerspruch zum nur Suchen aus äußerer Sicht und meistens ist ja dann auch das Aufsuchen eines der Suchergebnisse beabsichtigt. find liefert die dafür benötigten Pfadbezeichnungen.
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. 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. Wenn ich schreibe find -size +4GB -name "*.txt" sucht find nach einer solchen Datei, aber find sucht sie nicht auf, denn es gibt gar keine, die aufgesucht werden könnte.
Erst danach (dem Spruch) geht es dann im Artikel wieder speziell um den Befehl find .
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.!
Vielleicht ist im Kontext des Spruchs auch "zugreifen" weniger irritierend als "aufsuchen".
Haha, Find-Polizei, Zugriff! 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.
Es geht nicht darum, dass Dateieinträge im Dateisystem aufgesucht werden,
Für die korrekte Erläuterung des Spruchs meiner Ansicht nach schon. Für den nachfolgend beschriebenen Umgang mit find nicht unbedingt, weshalb ich ja auch den Zusatz "im Dateisystem" im Artikeltext nicht verwendet habe auch wenn das im Hintergrund immer passiert. Die Benutzung der Suche mit find soll dem Leser vermittelt werden, die zugrundeliegende Technik nur soweit es unabdingbar ist.
Zustimmung, der Einschub mit dem Spruch muss darauf aber nicht einschränkend inkorrekt formuliert sein.
Was soll denn hier inkorrekt sein, außer Methoden (Kriterien passt besser) vielleicht und aufsuchen, was es nicht ist. Ich werde immer sicherer, dass "und nach den gleichen Kriterien gesucht werden." die bessere Lösung ist.
Kriterien sind das, was der User find übergibt, wärend die Art, wie find damit dann arbeitet, die Methode ist.
Das ist für den User manchmal nützlich zu wissen aber die meisten User dürften eine Vorstellung vom Dateisystem haben, bei dem die Metainformationen und die Daten eine Einheit bilden.
Diese User dürften aber eher die Suchfunktion eines Dateibrowsers nutzen. Selbst ich gehörte bislang zu diesen. Den wenigen, die sich die Mühe machen, sich mit der komplizierten find -Syntax herumzuschlagen, traue ich dieses "Basiswissen" über Dateihaltung zu.
Für einfache Fragen ist die find-Syntax ja einfach.
Ich habe eben mal geschaut, ob und wo mein Dateibrowser überhaupt eine Suche hat, und was die zu bieten hat (Thunar). Das ist ja das nackte Elend! Da wir ein Forum sind will man manchmal die User auf die Suche (nicht: Aufsuche) schicken, und postet dann einen find-Befehl und setzt vielleicht einen Link zum Artikel. Vorwissen kann nicht viel vorrausgesetzt werden.
Solange alles rund läuft arbeite ich auch mit diesem einfachen, aber anschaulichen Modell. Wenn ich mit find arbeite suche ich meist eine Datei, aber oft suche ich die Datei dann nicht auf.
Ich auch, dazu brauche ich aber nicht die Hintergrundinfo, die mittels des Spruchs für Klarheit im Sonderfall sorgen soll. Und nur im Sonderfall wird man find bemühen, sonst eher die Suchfunktion eines Dateibrowsers.
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. 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.
|