UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3023
Wohnort: Köln
|
user_unknown schrieb: Da Dich der Punkt hat stolpern lassen habe ich ihn durch "das aktuelle Verzeichnis" ersetzt - was hältst Du davon?
Das verhindert zumindest, dass man aufgrund des langen Strichs mit nur einem Wort dahinter in Zweifel kommmt ob da ein Darstellungsfehler der Webseite vorliegt. So fällt mir aber jetzt wieder auf, was mir noch so hoch kam. "liefert sie aber nicht als Treffer" spült auch die Frage hoch, als was liefert find sie denn dann, wenn nicht als Treffer, von denen im ganzen Artikel bisher nicht die Rede war. Auch deshalb schien mir der Ausdruck "diese selbst" rein vom Gefühl her befriedigender. Ich weiß, das kann ich nicht mit irgendeiner Logik begründen. Wenn ich mir vorstelle, ich würde den Artikel das erste mal so von oben nach unten lesen, dann würde ich zunächst lernen, das find meistens sucht, manchmal aber findet. Dann würde ich was über Startpunkte lernen usw. Bei der Option -mindepth 1 könnte ich dann von deren vielschichtiger Wirkung regelrecht "überwältigt" sein.
Zunächst sucht oder findet es nicht mehr, sondern durchsucht. Dann kommen auf einmal statt Startpunkte Startverzeichnisse ins Spiel. Würde man Startpunkte schreiben hätte man das Problem, dass Punkte in allen Dimensionen die Ausdehnung 0 haben, darin was zu suchen, klänge abwegig, und ab einem Startpunkt was zu suchen widerspricht wieder Deinem Verständnis. OK, irgendwann hat man gefressen, dass es um die Suche in Verzeichnissen ab Startpunkt(en) geht. Also um das, was find sowieso standardmäßig tut, also warum wird es hier explizit erwähnt. Dann erfährt man, dass find hier etwas liefert, sie, die Startverzeichnisse, auch dieses Verb gab's bisher nicht. Ja und als Treffer auch noch, hoops, war das ohne die Option -mindepth 1 nicht möglich? Irre, was sie alles kann. Und nun aber eben doch nicht, als was denn dann? Oder vielleicht andere Treffer, nur eben nicht Startverzeichnisse, aber was denn nun wirklich?
Es dauert evtl. ziemlich lange, bis man darauf kommt, dass es hier eigentlich um was ganz anderes geht, nämlich die evtl. störende ungewöhnliche (in Bezug zu ls ) Ausgabe von dem Punkt zu vermeiden (auszuschließen, verhindern ...) und im Sonderfall auch noch die explizit angegebenen Startpunkte. Sollten wir die Erklärung dieser Option nicht besser auf den tatsächlich gewünschten Effekt zielen lassen?
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
UlfZibis schrieb: user_unknown schrieb: Da Dich der Punkt hat stolpern lassen habe ich ihn durch "das aktuelle Verzeichnis" ersetzt - was hältst Du davon?
Das verhindert zumindest, dass man aufgrund des langen Strichs mit nur einem Wort dahinter in Zweifel kommmt ob da ein Darstellungsfehler der Webseite vorliegt. So fällt mir aber jetzt wieder auf, was mir noch so hoch kam. "liefert sie aber nicht als Treffer" spült auch die Frage hoch, als was liefert find sie denn dann, wenn nicht als Treffer, von denen im ganzen Artikel bisher nicht die Rede war. Auch deshalb schien mir der Ausdruck "diese selbst" rein vom Gefühl her befriedigender. Ich weiß, das kann ich nicht mit irgendeiner Logik begründen.
Mit der Logik der Revanche kann man das begründen.
Wenn ich mir vorstelle, ich würde den Artikel das erste mal so von oben nach unten lesen, dann würde ich zunächst lernen, das find meistens sucht, manchmal aber findet. Dann würde ich was über Startpunkte lernen usw. Bei der Option -mindepth 1 könnte ich dann von deren vielschichtiger Wirkung regelrecht "überwältigt" sein.
Ich weiß nicht mehr wer die Startpunkte ins Spiel gebracht hat. Wenn ich mich recht erinnere ging es los mit der Behauptung, die allgemeine Syntax für den Aufruf von find sähe so und so aus. Das war aber falsch. So wurden u.a. [-H] [-L] [-P] als auch die Möglichkeit multipler starting-points unterschlagen. Weder bei Ubuntuusers, noch bei U&L, AskUbuntu oder SO auf SE habe ich je eine Frage gesehen mit einer Verwendung mehrerer Startpunkt, noch mit den drei Parametern H, L, P. Wäre es nach mir gegangen, hätte man diese Startpunkte stillschweigend übergangen oder allenfalls 1x am Rande erwähnt. Es gab zwei große Änderungsinitiativen die sich beide dadurch auszeichneten, dass jemand seinen Geschmack walten ließ und große Änderungen ohne Begründung veranstaltete, und ich derjenige war, der seine Wahl begründete. Irgendwer meinte, man suche nicht in Verzeichnissen sondern ab Verzeichnissen. Abstruseste Vorschläge wurden gemacht. Kein Satz blieb auf dem anderen. Irgendwann war es mir zu bunt und ich rollte alles zurück und fummelte dann die verstreuten Verbesserungen, die es vereinzelt schon gab, wieder rein. Die Datumsgeschichte fällt mir da ein und das mit den Größen waren so Sachen. Ich glaube -size -1M heißt kleiner als 1 MB, aber da die Einheit MB ist, ist nur 0MB kleiner als 1MB oder sowas, dazu die Frage MB oder MiBi... Dann kommen ab und zu Leute vorbei, die eine Option, die sie mal benutzt haben, nicht finden, und dann auch aufgenommen sehen wollen. Das bläht den Artikel aber irrsinnig auf. Meine Idee war es, mit einfachsten Beispielen zu beginnen und zu leichten fortzuschreiten, sowie die nach meiner Erfahrung häufigsten Optionen zu zeigen und auch ein wenig elaborierten Stuff, um zeigen was möglich ist. Außerdem die häufigsten Fehler (Reihenfolge mancher Optionen, Klammern vergessen, Shellcode ohne Shellaufruf im -exec-Teil, ...). Es soll eine Starthilfe sein, kein erschöpfendes Repository, die sich geduldige, wissbegierige Einsteiger auch komplett durchlesen können und Leute, die kein Englisch können sollten damit die meisten einfachen Fragen selbst klären können. Für weitere Fragen gibt es sowohl die man- und infopages, als auch das Forum.
Was meinst Du genau?
Dann kommen auf einmal statt Startpunkte Startverzeichnisse ins Spiel. Würde man Startpunkte schreiben hätte man das Problem, dass Punkte in allen Dimensionen die Ausdehnung 0 haben, darin was zu suchen, klänge abwegig, und ab einem Startpunkt was zu suchen widerspricht wieder Deinem Verständnis.
In der Mathematik mögen Punkte keine Ausdehnung haben. Bei Punkten einer Tagesordnung oder die Punkte die ein Pointillist oder Impressionist setzt oder Startpunkten für eine Radtour sieht das anders aus.
OK, irgendwann hat man gefressen, dass es um die Suche in Verzeichnissen ab Startpunkt(en) geht. Also um das, was find sowieso standardmäßig tut, also warum wird es hier explizit erwähnt.
Schmeißen wir die Mehrzahl überall raus und fügen für Pfennigfuchser eine Fußnote an, dass man mehrere Ausgangspunkte für die Suche festlegen kann, näheres verraten Arzt und Apotheker.
Dann erfährt man, dass find hier etwas liefert, sie, die Startverzeichnisse, auch dieses Verb gab's bisher nicht.
Jedes Wort in einem Text kommt irgendwann erstmalig darin vor. Wenn Dir das Schwierigkeiten macht - wieso machst Du nicht Sport oder Musik?
Ja und als Treffer auch noch, hoops, war das ohne die Option -mindepth 1 nicht möglich? Irre, was sie alles kann. Und nun aber eben doch nicht, als was denn dann? Oder vielleicht andere Treffer, nur eben nicht Startverzeichnisse, aber was denn nun wirklich?
Wenn Du dazu eine echte Frage hast bemüh doch Shell & Programmieren, da wird man Dir das sicher erklären, wenn Du konkretisierst, worauf Du selbst Dich beziehst.
Es dauert evtl. ziemlich lange, bis man darauf kommt, dass es hier eigentlich um was ganz anderes geht, nämlich die evtl. störende ungewöhnliche (in Bezug zu ls ) Ausgabe von dem Punkt zu vermeiden (auszuschließen, verhindern ...) und im Sonderfall auch noch die explizit angegebenen Startpunkte.
Hab' ich nicht eingebracht. Wenn der Punkt als Treffer geliefert wird, dann offensichtlich, weil er den Suchkriterien entspricht. Würde er nicht aufgelistet fänden das wieder andere seltsam. Muss man eben nachschauen, überlegen und experimentieren, wenn das wichtig ist.
Sollten wir die Erklärung dieser Option nicht besser auf den tatsächlich gewünschten Effekt zielen lassen?
In der Regel kommt einer, ändert den Artikel, und ich diskutiere dann das für und wieder. Dann kommt der nächste und ich diskutiere mit dem. Dann kommt wieder wer, der will wieder was anderes. Mit viel Engagement kommt mal eine dritte oder vierte Meinung aus dem Forum aber von selbst kommt nichts. Die Leute haben eben auch noch anderes zu tun. Der Artikel ist auch so lang, dass man einen Satz liest und dies oder jenes vielleicht besser fände, aber wenn man den ganzen Abschnitt liest ändert sich vielleicht die Meinung, etwa bzgl. suchen/finden. Und liest man den Abschnitt davor und danach bzw. den ganzen Artikel sieht es vielleicht wieder anders aus. Man will aber nicht für jeden Pup den ganzen Artikel noch mal von vorne bis hinten durchkauen - zumal man sicher dabei weitere Stellen findet, die nicht optimal sind unter diesem oder jenem Gesichtspunkt. Die jetztige Form ist bereits ein hart erkämpfter Kompromiss. Von Rechtschreibfehlern und Kommasetzung abgesehen ist da wenig zu finden, was man ohne Diskussion und Begründung einfach ändern kann.
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28956
Wohnort: WW
|
Hallo,
Die jetztige Form ist bereits ein hart erkämpfter Kompromiss. Von Rechtschreibfehlern und Kommasetzung abgesehen ist da wenig zu finden, was man ohne Diskussion und Begründung einfach ändern kann.
Sehr schön gesagt, +1. Gruß, noisefloor
|
UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3023
Wohnort: Köln
|
user_unknown schrieb: Die Frage ist, auf wen sich das "selbst" bezieht. Und das Subjekt des Satzes ist find, nicht die Verzeichnisse.
Wie kommst Du darauf, dass sich "selbst" nur auf das Subjekt eines Satzes beziehen darf, und nicht genauso legitim auch auf ein Objekt?
Durch naives Fragen:
"Find durchsucht die Startverszeichnisse, liefert sie selbst aber nicht als Treffer." "Wen oder was liefert find selbst nicht als Treffer?" "Startverzeichnisse." ("Wer dann liefert sie?") "Wen oder was liefert find nicht als Treffer?" "Startverzeichnisse selbst."
Was verdeutlicht in Punkt 3 das "selbst"? Nichts.
Damit erklärst Du zwar, warum Du "selbst" hier für überflüssig hältst, ich sehe darin aber keine Antwort auf meine Frage. user_unknown schrieb: Selbst ist eine Betonung und bezieht sich auf etwas, aber ist nicht selbst ein Bezug, wie "die, diese, letzteres".
Hm, ich höre und verwende die "feststehenden" Ausdrücke "er selbst", "sie selbst", "diese selbst" etc. oft. Wo habe ich behauptet, dass die Betonung "selbst" selbst ein Bezug ist? "selbst" verstehe ich in meinem Fall als Betonung des Bezugs, und "diese" ist wiederum die betonende Form von "sie". Selbstverständlich gibt es aber keine Regel die hier die Verwendung von Betonungen tatsächlich erzwingt. In unserem Fall würde es aber IMHS die Erfassung der gemeinten Bedeutung der holprigen Erklärung zu -mindepth 1 erleichtern, zumindest jedoch nicht erschweren. Weiteres Beispiel: Erna bringt einen Kuchen zur Geburtstagsfeier ihrer Schwester mit, diese selbst hatte aber auch schon einen gebacken.
Hier bezieht sich "selbst" auf den Bezug "diese" und weder unmittelbar noch mittelbar auf das Subjekt Erna.
Diese Schreibe verdient keinen Dichterpreis, wird aber dennoch gerne zur Betonung verwendet. user_unknown schrieb: Mit der Logik der Revanche kann man das begründen.
Dadurch, dass die Meinungsverschiedenheit ja erst mal in die Betrachtung der Korrektheit der Grammatik ausuferte, ging mir der Fokus darauf erst mal verloren. Deine Grammatikkritik lieferte bisher aber keinen Etappensieg, so sind wir noch im Hinspiel.
Wäre es nach mir gegangen, hätte man diese Startpunkte stillschweigend übergangen oder allenfalls 1x am Rande erwähnt.
Das Problem ist, dass man sich bei der intuitiven Herangehensweise durch Probieren (z.B. ausgehend von der Syntax von grep ) ziemlich schnell mit dem Vorhandensein der Startpunkte in der Syntax von find befassen muss. Mein erster Versuch sah in etwa so aus: find "*.jpg"
Nach einer gewissen Zeit erinnert man sich immerhin daran, dass ein Suchkriterium erforderlich ist und schreibt ausgehend von der Erfahrung mit vielen anderen Befehlen wie z.B. apt-get install ... find name "*.jpg" oder find name="*.jpg" oder z.B. ausgehend von dd find -name="*.jpg" (Mir anfangs mehrfach passiert.) Mit find [...ziemlich kompliziert und nie gebraucht...] [Pfad...] [Suchkriterium ...] stößt man dann wieder zuerst auf die Startpunkte (hier als Pfad... getarnt). Um dann da noch (wieder) zu erkennen, dass die Syntax der zentral wichtigen Suchkriterien im Abschnitt "Tests" erläutert wird – genau genommen aber nur angedeutet und man immer noch nicht deren Syntax versteht – braucht es ganz schön Durchhaltevermögen, wenn man eigentlich tief in einem anderen Problem steckt, für das man "mal eben" was suchen wollte. Von daher finde ich es ziemlich gut, dass im Artikel find deutlich auf die Startpunkte hingewiesen wird, nachdem man von find --help evtl. ziemlich verwirrt und enttäuscht war.
Was meinst Du genau?
Die hier folgende Liste war als satirische Übertreibung zu verstehen, als aufheiternde Hinführung zum relevanten Punkt: Sollten wir die Erklärung dieser Option nicht besser auf den tatsächlich gewünschten Effekt zielen lassen?
Vorschläge, gerne kombinierbar:
verhindert die Ausgabe von . verhindert die Ausgabe von . in der Liste der Suchergebnisse verhindert die Ausgabe von . – hier der Startpunkt verhindert die Auswertung des Startpunkts – hier das aktuelle Verzeichnis . vermeidet die Auswertung des Startpunkts – hier . – und damit dessen mögliches Erscheinen in der Ergebnisliste verhindert die Auswertung des Startpunkts selbst – hier das aktuelle Verzeichnis . – und dessen mögliches Erscheinen im Suchergebnis
Da die Option -mindepth ziemlich selbsterklärend ist, lenkt hier die Betonung auf dessen normale Funktion und der von find vom Erfassen der Lösung für das "Punkt-Problem" ab, die sicher von manchen Usern gesucht wird und was damals mein eigentlicher Grund war, diesen Sonderfall -mindepth 1 hier als Beispiel aufzuführen.
Wenn der Punkt als Treffer geliefert wird, dann offensichtlich, weil er den Suchkriterien entspricht. Würde er nicht aufgelistet fänden das wieder andere seltsam.
Nach dieser Logik können es wieder andere dann aber seltsam finden, dass ".." wiederum unterschlagen wird.
Die jetztige Form ist bereits ein hart erkämpfter Kompromiss. Von Rechtschreibfehlern und Kommasetzung abgesehen ist da wenig zu finden, was man ohne Diskussion und Begründung einfach ändern kann.
+1. Sorry, an zweitletzteres hatte ich hier tatsächlich nicht gedacht, geschuldet der Erfahrung mit vielen anderen Artikeln, wo man im Diskussionsfaden auf sowas unbedeutendes monatelang keine Reaktion sieht, sich andererseits aber zahlreiche solche "spontanen" nicht wirklich wichtigen lediglich geschmacklichen Änderungen aber auch gewichtigere mit der lapidaren Begründung "m" finden lassen – ja noisefloor, auch Du darfst Dich da angesprochen fühlen 😉 .
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
UlfZibis schrieb: user_unknown schrieb: Die Frage ist, auf wen sich das "selbst" bezieht. Und das Subjekt des Satzes ist find, nicht die Verzeichnisse.
Weiteres Beispiel: Erna bringt einen Kuchen zur Geburtstagsfeier ihrer Schwester mit, diese selbst hatte aber auch schon einen gebacken.
Hier bezieht sich "selbst" auf den Bezug "diese" und weder unmittelbar noch mittelbar auf das Subjekt Erna.
Diese Schreibe verdient keinen Dichterpreis, wird aber dennoch gerne zur Betonung verwendet.
Eben, genau was ich sage:
find -mindepth 1 durchsucht die Startverszeichnisse, liefert sie aber nicht als Treffer – hier .
Das selbst hilft nicht bei der Analyse, worauf sich das sie bezieht. Das mass man schon wissen, bevor das selbst etwas betonen könnte. Das ist der Punkt - das selbst hilft bei der Frage nicht. Es kann also weg, weil kein Bedarf daran besteht etwas zu betonen. Wie immer sucht find nach Dateien, so auch hier. Das selbst bringt nur Verwirrung in den Satz. Liefert find selbst oder die Verzeichnisse selbst? Dass das selbst den von Dir gewünschten Effekt nicht hat, dabei bleibe ich, und m.E. hast Du das bestätigt, in dem Du sagst, dass es etwas betont, was man schon entschieden haben muss.
user_unknown schrieb: Mit der Logik der Revanche kann man das begründen.
Dadurch, dass die Meinungsverschiedenheit ja erst mal in die Betrachtung der Korrektheit der Grammatik ausuferte, ging mir der Fokus darauf erst mal verloren. Deine Grammatikkritik lieferte bisher aber keinen Etappensieg, so sind wir noch im Hinspiel.
Das war Matt.
Wäre es nach mir gegangen, hätte man diese Startpunkte stillschweigend übergangen oder allenfalls 1x am Rande erwähnt.
Das Problem ist, dass man sich bei der intuitiven Herangehensweise durch Probieren (z.B. ausgehend von der Syntax von grep ) ziemlich schnell mit dem Vorhandensein der Startpunkte in der Syntax von find befassen muss. Mein erster Versuch sah in etwa so aus: find "*.jpg"
Mit Intuition, also göttlicher Eingebung, kann man nicht argumentieren. Deine Intuitionen sind erst mal nur Deine Intuitionen. Grep ist nicht normativ oder prototypisch für die Handhabung von Dateinamen und Parametern. Es ist nicht mal entfernt zur find-Syntax ähnlich. Für die einfachste Form des find-Befehls, find, hat grep nicht mal ein Äquivalent sondern gibt eine Fehlermeldung aus.
Nach einer gewissen Zeit erinnert man sich immerhin daran, dass ein Suchkriterium erforderlich ist
Dann erinnert man sich falsch. Ein Suchkriterium ist nicht erforderlich. Wenn man auf diesem Wissensstand gegen die Wand fährt sollte man das Wiki komplett von vorne lesen oder die Manpage. Es kann nicht die Aufgabe des Wikiartikels sein, mitten drin nochmal alles von vorne zu erklären. Würde man es tun würde es der Leser, der eben gescheitert ist, hier wieder überspringen - man wäre also keinen Schritt weiter.
und schreibt ausgehend von der Erfahrung mit vielen anderen Befehlen wie z.B. apt-get install ... find name "*.jpg" oder find name="*.jpg" oder z.B. ausgehend von dd find -name="*.jpg" (Mir anfangs mehrfach passiert.)
Entweder man hat Erfahrung mit vielen anderen Befehlen, dann weiß man, dass es keine programmübergreifende Parametersyntax gibt, sondern dass man es nachschlagen oder ausprobieren muss. Oder man hat gar keine Erfahrung. Da gibt es keinen magischen Zauberspruch, mit dem man alle möglichen Missverständnisse am Anfang des Artikels ausräumen kann. Eine feierliche Einleitung, dass dem so ist, kann man sich auch sparen, denn sie könnte vor jedem Wikiartikel stehen. Dann kann man sie auch weglassen. Sie ist nicht find-spezifisch.
Mit find [...ziemlich kompliziert und nie gebraucht...] [Pfad...] [Suchkriterium ...] stößt man dann wieder zuerst auf die Startpunkte (hier als Pfad... getarnt). Um dann da noch (wieder) zu erkennen, dass die Syntax der zentral wichtigen Suchkriterien im Abschnitt "Tests" erläutert wird – genau genommen aber nur angedeutet und man immer noch nicht deren Syntax versteht – braucht es ganz schön Durchhaltevermögen, wenn man eigentlich tief in einem anderen Problem steckt, für das man "mal eben" was suchen wollte. Von daher finde ich es ziemlich gut, dass im Artikel find deutlich auf die Startpunkte hingewiesen wird, nachdem man von find --help evtl. ziemlich verwirrt und enttäuscht war.
Am 29.11.2013 hat aasche die vorherige Gliederung https://wiki.ubuntuusers.de/find/a/revision/654937/ über den Haufen geworfen, die genau damit begann: Der Befehl find ohne Path oder Parameter, damals Startverzeichnis(se) benannt (die Manpage ist im Laufe der Jahre irgendwann auf starting points umgeschwenkt), Bemerkung "Gliederung". Ich habe das kritisiert und meine Ansicht begründet https://forum.ubuntuusers.de/post/6157617/ aber keine Unterstützung dafür erhalten und kein Feedback.
Was meinst Du genau?
Die hier folgende Liste war als satirische Übertreibung zu verstehen, als aufheiternde Hinführung zum relevanten Punkt: Sollten wir die Erklärung dieser Option nicht besser auf den tatsächlich gewünschten Effekt zielen lassen?
Vorschläge, gerne kombinierbar:
verhindert die Ausgabe von . verhindert die Ausgabe von . in der Liste der Suchergebnisse verhindert die Ausgabe von . – hier der Startpunkt verhindert die Auswertung des Startpunkts – hier das aktuelle Verzeichnis . vermeidet die Auswertung des Startpunkts – hier . – und damit dessen mögliches Erscheinen in der Ergebnisliste verhindert die Auswertung des Startpunkts selbst – hier das aktuelle Verzeichnis . – und dessen mögliches Erscheinen im Suchergebnis
Da die Option -mindepth ziemlich selbsterklärend ist, lenkt hier die Betonung auf dessen normale Funktion und der von find vom Erfassen der Lösung für das "Punkt-Problem" ab, die sicher von manchen Usern gesucht wird
Bestreite ich.
und was damals mein eigentlicher Grund war, diesen Sonderfall -mindepth 1 hier als Beispiel aufzuführen.
Wenn der Punkt als Treffer geliefert wird, dann offensichtlich, weil er den Suchkriterien entspricht. Würde er nicht aufgelistet fänden das wieder andere seltsam.
Ich bestreite, dass mehr als 1 User pro Jahr auf der Suche nach dem speziellen Problem im Wiki landet und dann auch noch die Stelle findet, die sein Problem behandelt. Stattdessen wird dem ganzen eine Aufmerksamkeit gewidmet, die eher viele Leute in die Irre führt, weil sie sich fragen was das soll, wofür das wichtig ist und die sich fragen, was sie nicht verstanden haben. Das Problem ist zu speziell für's Wiki nach meinem Geschmack und eignet sich auch nicht dafür wie hier den Usern heimlich als Beispiel untergejubelt zu werden, so dass es von der Länge den Artikel nicht belastet, weil es zu viele Implikationen gibt mit dem Punkt. Zudem ist es auch nicht die einzige oder kanonische Lösung des Problems, find ! -name "." liegt hier eigentlich näher.
Nach dieser Logik können es wieder andere dann aber seltsam finden, dass ".." wiederum unterschlagen wird.
Das klingt als sei das ein Problem. Wer das seltsam findet, der hat es gemerkt und hat schon was gelernt.
Die jetztige Form ist bereits ein hart erkämpfter Kompromiss. Von Rechtschreibfehlern und Kommasetzung abgesehen ist da wenig zu finden, was man ohne Diskussion und Begründung einfach ändern kann.
+1. Sorry, an zweitletzteres hatte ich hier tatsächlich nicht gedacht, geschuldet der Erfahrung mit vielen anderen Artikeln, wo man im Diskussionsfaden auf sowas unbedeutendes monatelang keine Reaktion sieht, sich andererseits aber zahlreiche solche "spontanen" nicht wirklich wichtigen lediglich geschmacklichen Änderungen aber auch gewichtigere mit der lapidaren Begründung "m" finden lassen – ja noisefloor, auch Du darfst Dich da angesprochen fühlen 😉 .
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8565
|
Hallo in die Runde, find foo sucht in foo im aktuellen Verzeichnisses. Das ist sicher missverständlich. Ist vllt das hier richtig? sucht im aktuellen Verzeichnisses nach einem Verzeichnis oder einer Datei "foo" . Hieraus abgeleitet:
mate-hp@matehp-HP:~$ find foo
find: ‘foo’: Datei oder Verzeichnis nicht gefunden
mate-hp@matehp-HP:~$ oder habe ich da was völlig falsch verstanden? Sollte mein Vorschlag okay sein, dann ändere ich das ab.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8558
Wohnort: Münster
|
Berlin_1946 schrieb: […]
find foo sucht in foo im aktuellen Verzeichnisses. Das ist sicher missverständlich.
Aber fast richtig. foo wird hier von find als Angabe eines Startpunktes in Form eines relativen Pfades verstanden. Also bearbeitet find das Verzeichnis -/foo/ und listet rekursiv alle Dateien darin auf. Natürlich vorausgesetzt, ./foo/ existiert überhaupt, sonst Fehlermeldung. Ganz richtig: « … listet rekursiv das Verzeichnis ./foo/.»
Ist vllt das hier richtig? sucht im aktuellen Verzeichnisses nach einem Verzeichnis oder einer Datei "foo" .
Nein. Das Wort „Suchkriterium“ wird der Arbeitsweise von find in keiner Weise gerecht und führt in die Irre. find sucht überhaupt nichts, sondern liefert eine rekursive Liste aller Dateinamen ab einem oder mehrerer Verzeichnissen als Startpunkte, und es filtert diese Liste nach zahlreich möglichen und kombinierbaren Kriterien, und es ermöglicht Aktionen auf der gefilterten Liste. Man sollte also im Wiki-Artikel von Filterkriterien anstatt Suchkriterien sprechen.
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28956
Wohnort: WW
|
Hallo,
foo wird hier von find als Angabe eines Startpunktes in Form eines relativen Pfades verstanden.
Nee, stimmt nicht. Ja, es stimmt, wenn foo ein Verzeichnis ist. Ist foo eine Datei, wird diese von find aufgelistet (und ist dann logischerweise die einzige Ausgabe von find . Habe die letzte Änderung deswegen zurückgesetzt, weil in der Form falsch. Gruß, noisefloor
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8565
|
Sry, aber ich finde die Erklärung schwer verständlich. Erst mit der Erklärung von kB habe ich das verstanden. So ist es doch gemeint oder mein-test@meintest-VirtualBox:~$ cd Dokumente/ # ins aktuelle Verzeichnis gewechselt
mein-test@meintest-VirtualBox:~/Dokumente$ ls -l
insgesamt 4
drwxrwxr-x 3 mein-test mein-test 4096 Feb 5 17:27 foo # Ins Verzeichnis foo gewechselt, damit das Ergebnis beurteilt werden kann
mein-test@meintest-VirtualBox:~/Dokumente$ cd foo/
mein-test@meintest-VirtualBox:~/Dokumente/foo$ ls -l
insgesamt 8
drwxrwxr-x 2 mein-test mein-test 4096 Feb 5 17:27 nur_so # ein Verzeichnis und
-rw-rw-r-- 1 mein-test mein-test 5 Feb 5 17:05 test.txt # und eine Datei sind im foo
mein-test@meintest-VirtualBox:~/Dokumente/foo$ cd .. # zurück ins aktuelle Verzeichnis um den foo- Befehl zu testen
mein-test@meintest-VirtualBox:~/Dokumente$ find foo
foo
foo/test.txt # die Datei
foo/nur_so # das leere Verzeichnis
mein-test@meintest-VirtualBox:~/Dokumente$
aus dem Wiki: sucht in foo im aktuellen Verzeichnisses.
Das ist das eigentliche Ergebnis: die Datei test.txt und das Verzeichnis nur_so im Verzeichnis foo . Das sagt alles das in aus. Finde ich etwas (-dünne- auf Hochdeutsch) schwach erklärt. Mein Vorschlag (ist als Diskussionsverschlag gemeint): "sucht in Verzeichnis foo , der Befehl find wird im aktuellen Verzeichnisses ausgeführt." 😇 (so würde ich es leichter verstehen)
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28956
Wohnort: WW
|
Hallo,
Sry, aber ich finde die Erklärung schwer verständlich.
Das stimt.
Erst mit der Erklärung von kB habe ich das verstanden.
Ja, aber die war / ist so ja auch nicht komplett korrekt. Habe das Beispiel mit mehr Text versehen. Gruß, noisefloor
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8565
|
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8558
Wohnort: Münster
|
noisefloor schrieb: […] foo wird hier von find als Angabe eines Startpunktes in Form eines relativen Pfades verstanden.
Nee, stimmt nicht. Ja, es stimmt, wenn foo ein Verzeichnis ist. Ist foo eine Datei, wird diese von find aufgelistet (und ist dann logischerweise die einzige Ausgabe von find .
Doch, doch mein Statement stimmt voll und ganz! Dass es für Verzeichnisse stimmt, hast Du ja schon zugegeben. find akzeptiert neben Verzeichnissen aber auch reguläre Dateien als Startpunkt, obwohl das eigentlich sinnlos ist. Es macht dann auch genau dasselbe wie bei einem Verzeichnis als Startpunkt, nämlich listet alles, was an Dateien unter dem Startpunkt liegt. Da dies natürlich bei regulären Dateien die leere Menge ist, wird nur der Startpunkt gelistet. Das man find zwar eine reguläre Datei als Startpunkt geben kann, dies aber normalerweise nicht machen soll, bemerkt man durch Benutzung der Tab-Vervollständigung. Man bekommt dann per eingebauter Weisheit als Kandidaten für den Startpunkt nur die Verzeichnisse im aktuellen Verzeichnis gezeigt, weil reguläre Dateien an dieser Stelle zwar möglich, aber eben sinnlos sind.
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28956
Wohnort: WW
|
Hallo,
weil reguläre Dateien an dieser Stelle zwar möglich, aber eben sinnlos sind.
Kannst ja mal einen Bugreport dafür einreichen. Gruß, noisefloor
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17548
Wohnort: Berlin
|
So sinnlos ist das nicht. Wenn man prüfen will, ob die Datei foo älter als 7321 aber jünger als 7327 Tage ist, kann man das mit find sehr gut machen, oder man eine mehr oder weniger wilde Kombination anderer Kriterien, die man mit find testen will; evtl. zielt man auch auf eine der -exec-Varianten ab. Mich wundert, wie hier alle das "Verzeichnisses" übersehen haben - muss natürlich "Verzeichnis" lauten.
sucht in foo im aktuellen Verzeichnis. Sollte foo ein Verzeichnis sein, werden alle darin enthaltenen Dateien und Verzeichnisse rekursiv aufgelistet. Sollte weder eine Datei noch ein Verzeichnis Names foo vorhanden sein, wird die Meldung find: foo: No such file or directory ausgegeben
Ist der Stand jetzt, aber gefällt mir nicht sonderlich. Den einleitenden Absatz unter "Startpunkte" soll man natürlich gelesen haben. Egal ob der Startpunkt /tmp, .., /, foo, foo bar baz oder was immer ist - es werden immer, wenn es ein oder mehrere Verzeichnisse sind, alle darin enthaltenen Dateien rekursiv aufgelistet, das ist nicht spezifisch für foo und könnte man unter jedem Punkt wiederholen, was natürlich Quatsch wäre. Wenn der Startpunkt nicht gefunden wird kommt auch immer die Fehlermeldung, auch das gehört nicht spezifisch zu foo. Startpunkte geben an, wo gesucht werden soll, nicht was gesucht werden soll. Ein find foo ist natürlich kürzer, als find -maxdepth 1 -name foo , aber noch kürzer ist natürlich ls -d foo , wenn man nur wissen will, ob die Datei da ist. Ein find foo hat also nur Sinn, wenn foo ein Verzeichnis ist oder weitere Befehle für find noch folgen. Üblicherweise haben die meisten ordinären Dateien ja auch einen Punkt und eine Dateiendung, d.h. es drängt sich irgendwie auf, dass foo ein Verzeichnis ist, aber es ist eben nicht zwingend eins. Ich habe es auf
sucht in foo im aktuellen Verzeichnis.
zurückgesetzt, mit der Korrektur von Verzeichnisses . Die 3 Wörter vor dem Listeneintrag sind auch, auch aus Einheitlichkeitsgründen, eliminiert worden.
|
Berlin_1946
Supporter, Wikiteam
Anmeldungsdatum: 18. September 2009
Beiträge: 8565
|
user_unknown schrieb: So sinnlos ist das nicht.
Wenn man prüfen will, ob die Datei foo älter als 7321 aber jünger als 7327 Tage ist, kann man das mit find sehr gut machen, oder man eine mehr oder weniger wilde Kombination anderer Kriterien, die man mit find testen will; evtl. zielt man auch auf eine der -exec-Varianten ab.
Was hat das vorgenannte jetzt mit der Änderung bzw. mit der aktuellen Diskussion zu tun? Hier wurden nie über die Punkt "alte, jünger und/oder Tage" diskutiert. Das versehe ich leider auch nicht, wie du das meinst Datei foo . Wenn es um den Befehl find foo geht, dann muss foo ein Verzeichnis im aktuellen Verzeichnis sein. | mate-hp@matehp-HP:~$ find foo
find: ‘foo’: Datei oder Verzeichnis nicht gefunden
mate-hp@matehp-HP:~$ ls -lauh| grep -i foo
-rw-rw-r-- 1 mate-hp mate-hp 14 Feb 13 09:54 foo.txt
mate-hp@matehp-HP:~$ find foo*
foo.txt
mate-hp@matehp-HP:~$
|
zu:
im Home, dem aktuellen Verzeichnis wird find foo aufgerufen nichts gefunden. Datei oder Verzeichnis nicht gefunden die Zeilen 3 und 4 zeigen, es gibt eine Datei foo.txt wenn Dateien gefunden werden sollen, dann ist das der Befehl find foo* (siehe auch das Beispiel find Film* in diesem Wiki)
Das Wort "Verzeichnisse" (also Mehrzahl) ist aus meiner Sicht richtig , zeigt doch dieses andere Beispiel:
mate-hp@matehp-HP:~$ ls -lauh| grep -i foo
drwxrwxr-x 4 mate-hp mate-hp 4,0K Feb 13 14:17 foo
-rw-rw-r-- 1 mate-hp mate-hp 14 Feb 13 14:16 foo.txt
mate-hp@matehp-HP:~$
der Befehl find foo zeigt:
mate-hp@matehp-HP:~$ find foo
foo # ist ein Verzeichnis im Home (~)
foo/foo1 # ist ein Verzeichnis im Verzeichnis `foo`
foo/foo1/foo1.txt # Datei im Verzeichnis `foo1`
foo/foo3.txt
foo/.~lock.foo.txt#
foo/foo2 # ist ein Verzeichns im Verzeichnis `foo`
foo/foo2/foo2.txt # Datei im Verzeichnis `foo2`
mate-hp@matehp-HP:~$ Ins Verzeichnis foo gewechselt,
Codemate-hp@matehp-HP:~/foo$ ls -lauh| grep -i foo
drwxrwxr-x 2 mate-hp mate-hp 4,0K Feb 13 10:23 foo1
drwxrwxr-x 2 mate-hp mate-hp 4,0K Feb 13 10:23 foo2
-rw-rw-r-- 1 mate-hp mate-hp 14 Feb 13 09:54 foo3.txt
-rw-rw-r-- 1 mate-hp mate-hp 79 Feb 13 09:54 .~lock.foo.txt#
mate-hp@matehp-HP:~/foo$
ist zu sehen, das es 2 Verzeichnisse gibt (gelb markiert). Ich erkenne bei:find foo foo muss ein Verzeichnis im aktuellen Verzeichnis sein. Der Startpunkt ist das Verzeichnis foo in dem wird rekursiv nach allen Verzeichnissen und Daten gesucht die foo enthalten.
Und noch ein Beispiel: mate-hp@matehp-HP:~$ cd foo/
mate-hp@matehp-HP:~/foo$ find foo # in Verzeichnis `foo` gibt es die Verzeichnisse `foo1` und `foo2` sowie die Datei `foo.txt`
find: ‘foo’: Datei oder Verzeichnis nicht gefunden
mate-hp@matehp-HP:~/foo$ find foo1 # ein Verzeichnis als Startpunkt im aktuellen Verzeichnis zeigt wieder Ergebnisse.
foo1
foo1/foo1.txt
mate-hp@matehp-HP:~/foo$
Sry aber diesen Zusammenhang kann ich leider nicht in diesem Satz - sucht in foo im aktuellen Verzeichnis.- erkennen, auch wenn ich vorher Startpunkt gelesen habe.
|