Keiner dieser Sätze mit zu ist ein Nebensatz. Aber es ist wahrscheinlich auch sinnlos, du hast sowieso recht und bist uns sprachlich allen haushoch überlegen, weshalb wir deiner sprachlichen Perfektion hier noch ein paar Seiten Raum geben.
find
Anmeldungsdatum: Beiträge: 29240 Wohnort: Germany |
|
||||||||
Anmeldungsdatum: Beiträge: 7657 |
http://www.duden.de/rechtschreibpruefung-online sagt dazu:
|
||||||||
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
Hey, bitte entspann Dich, "was dazu gelernt" meinte ich auch so. Laut Frostschutz sind wohl beide Schreibweisen richtig, was ich vorher nicht wusste.
Ob "Fehler zu vermeiden" ein Nebensatz ist, und "Mit Rucksack zu laufen" keiner, weiß ich nicht, weder das eine noch das andere hatte ich behauptet. |
||||||||
Anmeldungsdatum: Beiträge: 8020 Wohnort: Süsel / Ostholstein |
Moin Moin,
Und das sagt Wikipedia https://de.wikipedia.org/wiki/Kommaregeln#Erweiterter_Infinitiv Beides ist richtig. Gruß |
||||||||
Ehemaliger
(Themenstarter)
Anmeldungsdatum: Beiträge: 29065 Wohnort: WW |
Hallo, hier geht es um den Artikel zu find - nicht im Details der Kommasetzungsregeln. Also bitte beim Thema bleiben. Wer da Diskussionsbedarf hat, startet bitte einen neuen Thread an passender Stelle. Was bei uu.de wohl die Lounge wäre.b Generell gilt: wer ein falsch gesetztes Komma im Wiki findet (und davon gibt es wahrscheinlich mehr als eins 😉 darf das korrigieren. @UlfZibis: bis du jetzt eigentlich fertig mit dem Artikel oder nicht? Gruß, noisefloor |
||||||||
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
Genau darauf wollte ich heraus. Ein Auto kann einen Mädchennamen haben, ist aber keins. Mit "Mercedes" habe ich im Verzeichnis der KFZ-Zulassungsbehörde nur bedingt eine Zugriffsmöglichkeit auf ein Mädchen.
... und lässt zu, dass auch ein Socket einen Dateinamen haben kann.
Datenträger wollte ich tatsächlich so allgemein verstanden wissen, also hardware-unabhängig. Dateisysteme wie Ext4 oder NTFS unterscheiden sich voneinander durch ihre Struktur, sind also dadurch festgelegt, würde ich sagen, und nicht durch die Software, z.B. Betriebssystem, die darauf zugreift.
Genau.
Aber genau diese muss er doch kennen, mit der Sternzeichen-Bezeichnungsmethode käme er nicht weiter. Und die sich aus der Baumstruktur ergebende Pfadnamen-Bezeichnungsmethode ist doch die, auf die unser Spruch hinweisen soll, egal ob damit Dateien oder sonstwas bezeichnet werden.
Nach einer find-Operation sind im Cache keine Dateien, sondern nur Dateinamen, eingetragen in einer Verzeichnisstruktur. Diese Einträge werden von
Unter SIP vielleicht, meine ist eine Nummer.
Genau, und in dieser Auflistung finden sich die Dateinamen und deren Eigenschaften ... als Einträge i(m|n) Verzeichnis(en), und die, die da waren, wurden aufgesucht.
Genau, nur das cat nicht die Zeichenfolge, die auf die Datei verweist, ausgibt, sondern den Inhalt der verwiesenen Datei, die dafür über cat aufgesucht wurde, nicht über find.
Steht doch 2 Zeilen tiefer, also dass unser Spruch nicht mit "kann deshalb mit gleichen Kriterien gesucht werden" erklärt werden kann, sondern eher mit "mit gleichen Methoden", also solchen, die mit Pfadbezeichnungen umgehen können. Im Melderegister führen letztere nicht zum Ziel, wohl aber gleiche Kriterien (Name, Alter ...).
Genau, weil find andere Methoden (die durch unseren Spruch ja u.a. herausgestellt werden sollen) nutzt und für ein anderes (Datei)-System "geschult" ist, als die Bedienstete im Meldeamt.
Nicht direkt, die Diskussion entstand aus meiner Formulierung ....
Und dann später ....
Mit der folgenden Formulierung wäre dieses Thema aber obsolet:
Ja, ganz genau so. Der Kranke sucht Namen von Ärzten und deren Adressen (Pfad dort hin), die sich mit Ohren (Kriterium) auskennen, wozu er die Einträge in den Gelben Seiten aufsucht. Und mit den gefundenen Adressen beauftragt er ein Taxi (-exec Taxi {Adresse}), welches mit der (Auf)suchmethode "Adresse" die Arztpraxis (oder auch mehrere) zur Nutzung "bereitstellt".
Genau.
Aber nicht von ihrem Wesen her, sondern durch die "Vereinbarung" über den Spruch.
Nur die Namen, wofür ich die Straßenverzeichniseinträge aufsuche, um sie mit meinen Kriterien auf Passung zu prüfen.
Bis zu einem bestimmten Punkt kann man das so machen, doch wenn es zu bestimmten Details kommt, kriegt man auch im Meldeamt Erklärungsnotstand. Z.B. mit
Hier würde ich schon sagen die Einwohner, wenn ich "erfasst" mit "verzeichnet" gleichsetzen darf.
Und so ein Buch ist ein Verzeichnis, deshalb bin ich mit "Dateiverzeichnis" d'accord. "
Oder doch nicht? |
||||||||
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
Auch, wenn ein Wikiteam-Mitglied einen vorher richtig gesetzten Bindestrich löscht?
Ich warte noch auf das Feedback von user_unknown bzgl. der neuen Vorschläge in 8832293 und der Diskussion der gefundenen Fehler und von noisefloor zu 8833329 zumindest bzgl. der strittigen Hauptwortzusammensetzungen. Gruß, Ulf
Und ich wäre mal neugierig, ob in obigem Satz jemand der Bezug zum Programm du aufgefallen ist. |
||||||||
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
Kleiner Nachtrag: Ich überlege, ob man nicht besser Meinungen? |
||||||||
Ehemaliger
(Themenstarter)
Anmeldungsdatum: Beiträge: 29065 Wohnort: WW |
Hallo, @UlfZibis: Du erweckst gerade stark den Eindruck, dass du bewusst auf Kleinigkeiten, die nicht direkten Einfluss auf den Inhalt haben, statt auf den Inhalt fokussierst, um... tja, warum? Von einem anderen Problem abzulenken? Egal, heute ist deine selbst gesetzt Deadline. Ich gehen davon aus, dass du die, nachdem die Bearbeitung des Artikel schon mal, sagen wir mal, schief gegangen ist, einhältst. Sprich, der Artikel wird heute _inhaltlich_ fertig gestellt, so dass der finale Review und das Fine-Tuning stattfinden kann. Also sag' bitte explizit Bescheid, wenn / das du _inhaltlich_ fertig bist. Gruß, noisefloor |
||||||||
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
Erste Gehversuche als Therapeut? 😉
Ok, dann mache ich mal fertig ohne vorheriges Feedback. |
||||||||
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
Ich hab' fertig mit der Baustelle! Das Beispiel find startpunkt -type d -execdir tar -cjf archiv.bz2 {} \; müsste aber vom Erfinder noch mal auf korrekte Funktion geprüft werden. |
||||||||
Anmeldungsdatum: Beiträge: 17552 Wohnort: Berlin |
@Ulf2Ibis: Find ist für mich im täglichen Gebrauch und Rahmen des Wikiartikels eine Blackbox. Man gibt find in die Befehlszeile ein und kann dann verschiedene weitere Knöpfe der Findmaschine drücken, und dann passiert was. Einmal natürlich abhängig vom Dateisystem (Teil des Dateisystems sind auch Sockets und Verzeichnisse) und zum anderen abhängig von den Knöpfen, die man drückt. Die Ziele, die die User damit verfolgen können wir nicht vorab erraten und sie sind zu verschieden um von spekulativen Zielen auszugehen. Stattdessen geht man so vor, dass man häufige Anwendungsfälle aus eigenen Erfahrungen und Erfahrungen im Support extrapoliert. Außerdem zerlegt man die häufigsten Fälle in Teile, die unabhängig voneinander erklärt werden können. Das klappt nicht immer - spätestens wenn es um die Kombination von Parametern geht muss man ja die Kombination erklären. Was man nicht erklären will ist, wie Find intern arbeitet. Die Methode. Auch das klappt nur bis zu einem gewissen Punkt: Wenn man erklären will, wieso der Test, was -delete löschen würde, ein -depth benötigt, muss man ein wenig über die Methode, wie find arbeitet, erklären, aber auch hier wird man auf einem möglichst abstrakten Niveau bleiben. Wenn ich eine Datei suche, die weniger als 24 h alt ist, dann interessiert mich das Kriterium, nicht die Methode.
Du scheinst da einen Widerspruch sehen zu wollen, der nicht existiert. Ich widerspreche nicht, dass es eine Nummer ist, ich sage, dass auch eine Nummer ein Name ist. So wie Tisch ein Name ist, der Name eine Möbelsorte. Ein Name ist eine Zeichenkette die etwas bezeichnet. Ein Möbelstück, eine Person, einen Telefonanschluss, eine Datei. Mein Eßtisch, Aretha Franklin, 110, /etc/passwd sind alles Namen, die etwas bezeichnen aber man kann vom Eßtisch essen - nicht von 110 und nicht von /etc/passwd. Man kann den Eßtisch nicht anrufen und /etc/passwd nicht. Aretha Fanklin ist keine Nummer und /etc/passwd hat keine Quersumme. Obwohl das alles Namen sind sind es auch die bezeichneten Dinge. Wenn man sich immer wieder ins Bewusstsein ruft, dass die Begriffe nicht das sind, worüber man spricht, sondern die Namen dafür, worüber man spricht, wird man kirre im Kopf. Im philosophischen Seminar kommt das mal vor (Grüße an Hegel, Wittgenstein und Sartre) aber im Alltag will man damit nichts zu tun haben. Der User sucht Dateien. Weil es Urlaubsbilder sind, ein Musikstück, dass er hören will, eine Doktorarbeit über Hegel, an der er seit 4 Monaten schreibt und für die er lange schon eine Sicherheitskopie anlegen wollte. Um damit zu arbeiten braucht er meist ihren Namen, nicht einfach DCIM0001.PNG sondern mit Pfad, damit es eindeutig ist, aber nicht immer sucht er den Namen. Manchmal genügt die Größe, manchmal genügt es zu wissen, dass es eine Datei mit den Kriterien gibt - gesucht wird die Datei. Nach welcher Methode das Betriebssystem Dateien verzeichnet interessiert für den Artikel nur ganz am Rande - soweit man mit diesem Wissen Find besser verstehen kann. Eine der Informationen ist, dass auch Verzeichnisse und Sockets für Find Dateien sind. Kriterien, die für andere Dateien zur Suche benutzt werden können, wie Suche nach Name, kann man auch auf Verzeichnisse anwenden. Die Methode, wie find das macht, ist die interne Sache von Find und interessiert nicht.
Was denn zum Beispiel? Hast Du wieder vergessen, dass unter Unix alles eine Datei ist?
Ja, ich speicher Dateien in Verzeichnissen ab um die später da wieder rauslesen zu können. Das ist genau das, was ich erwarte. Mit Sockets habe ich direkt keine Berührung. Oder ich kopiere Verzeichnisse, öffne sie, archiviere sie, benenne sie um usw.
Ich habe weder den Quellcode von Find studiert, noch den Linuxkernel und wie dort das Dateisystem implementiert ist. Wie gesagt - find ist für mich eine Blackbox und gemeinsam mit anderen Erfahrungen, die ich mit dem Dateisystem gesammelt habe, habe ich dennoch eine Art Modell im Kopf, was denn nun ein Dateisystem ist, wie es aussieht und was folglich eine Datei eigentlich ist. Daraus folgt, dass find Dateien sucht, nicht Dateinamen. Dass find Dateinamen per default ausgibt ist nur der Regelfall.
Wieso sollten Dateinamen hier eine Rolle spielen? Auch glaube ich nicht, dass die Dateien hier aufgesucht werden und find diese noch mal abschreitet, um deren Größe zu ermitteln, sondern ich vermute, dass die Größe auch verzeichnet ist. Sonst würde eine derartige Suche bei sehr großen Dateien auf langsamen Datenträgern sehr lange dauern. Man könnte höchstens sagen, dass insofern, als die Einträge im Verzeichnis mit den Dateien, die sie bezeichnen, identifiziert werden, die Dateien aufgesucht werden. Deswegen bin ich gegen diese künstliche Pseudoakkuratesse von Dateinamen und Einträgen und aufsuchen zu reden, solange man damit nicht wirklich etwas erklärt, was sonst missverständlich wäre. Infoseiten/Manpage: OK. -delete Aktion statt Option: OK. aber:
Vor ... vorausgehen ist doppelt. Besser:
Da es nicht ums Gehen geht ist vorausgehen auch nach neuer Schreibung m.w. zusammenzuschreiben.
Camelcase kommt in d. dt. Sprache nicht vor. Kilogramm, nicht KiloGramm, folglich Mebibyte, nicht MebiByte.
Ich finde die alte Version verständlicher.
Wieso "laut"? "Im Manual ... wird alles ... als Ausdruck benannt" oder "Laut Manual ist alles ... ein Ausdruck".
Wenn, dann "eigentlichen, hier nicht ..." aber wieso eigentlichen? Bist Du Heideggerianer? Das Wort "eigentlichen" einfach Löschen. Das war's zu neueren Änderungen. Jetzt noch mal den Vergleich mit 25. Jan. angesehen und folgendes anzumerken (von oben):
Das "kann" sagt bereits, dass es optional ist, daher muss das "auch" raus.
sucht nach einem Typ, gut. Nur schlecht.
Wieso Etiketten statt Marker? In dem Zusammenhang habe ich noch nie Etiketten gehört oder gelesen.
(statt ab aktuellem Verzeichnis) Gut!
Geläufige Aktionen für find.
Semikolon ist gut. Vielleicht sogar ". Neuer Satz"? Ergänzend:
Das ist nämlich bequemer im 10-Finger-System zu tippen.
Ist das so? Ich frage, weil die Manpage überraschend defensiv formuliert:
Wieso schreibt die Manpage "much less" und nicht "just once"? Kann es sein, dass find die maximale Argumentlänge berücksichtigt? Ich prüfe das jetzt nicht spontan nach, weil es eine sehr große Zahl ist - ich glaube über 100'000 Dateien sind möglich.
Wieso "extra"? Entweder es sind welche angegeben, oder nicht. Wenn keine angegeben sind, dann ... . Vorschlag:
Googlesuchen:
Die Anführungsstriche sind falsch, neben der Absicht, die dahinter steht, und die auch falsch ist. Verzeichnisse sind Dateien; das muss man nicht verinnerlichen, wenn man stur ist, aber man soll andere nicht manipulieren, diese Ansicht für normal zu halten.
Ja, ist besser.
Besser fände ich noch "analog" statt "ähnliches":
Ich muss jetzt einkaufen - später dann weiter ab Alter, Alter. 😉 |
||||||||
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
Aha, der Nerd beginnt sein Tag- ehm Nachtwerk.
Danach gehe ich ja vor. 😎 Was einfach ging, habe ich noch eingebaut. Ansonsten würde ich mich mal gerne um meine Facebook-Freunde kümmern, die habe ich wegen find schon über eine Woche sitzen lassen ... und morgen ist auch mal Sonntag. Mal sehen, hab' meiner Gesundheit versprochen, auch mal Pause zu machen. |
||||||||
Anmeldungsdatum: Beiträge: 17552 Wohnort: Berlin |
Weiter bei Alter: -ctime (mit Dash, nicht ohne) Prima!
Bei mir nicht:
"Von-bis" - hatte ich das nicht schon mal kommentiert? Was gefällt Dir nicht an von-bis? Das ist die gängige Formulierung. Wieso wieder so ein gekünsteltes Umstandssprech? Wenn das jetzt ein neuer Artikel wäre, aber wieso verbesserst Du die Formulierung? Ich meine Du must erklären, wieso in-bis besser ist als von-bis, nicht ich, wieso es umgekehrt ist.
Ich schlage eine Auszeichnung von oder und nicht vor. Keine Unterstreichung. Intuitiv tendiere ich zu kursiv, aber diese Wikikonventionen ... 😉
Sehr gut.
War "mit relativem Pfad" nicht inzwischen Konsens? Und ohne "nur". Immer dieses nur! Außerdem: Wenn ich einen Vergleich mache zwischen einer alten Version und der aktuellen, dann zeigt er mir natürlich an:
Aktuell sind es mehr Unterschiede, aber was ist der Vorteil der Satzumstellung? Dass ich jedes Mal drüber nachdenken darf, was Dein Motiv dafür war, wenn ich mir die Unterschiede anschaue? Ob da ein subtiler Unterschied besteht?
Ein super Fortschritt. Ein Glück, dass das verbessert wurde!
Zeitstempel ist besser. "gibt aber nichts aus" ist kompakter. + Jetzt noch das (ererbte) nun weg und wir haben einen weiteren Konsens.
Verbliebe. War im Original (existiert) auch falsch.
Das ist ja gerade der Witz an +. Nur wenn es keinen sichtbaren Unterschied in der Ausführung macht kann man ";" umstandslos mit "+" ersetzen. Ansonsten war das Kommando mit ";" falsch. find -name "*pdf" -exec du --total {} ";" --total macht ja hier gar keinen Sinn.
Kommt vielleicht auf die Realität an.
OR und AND statt UND und ODER, gut. Aber Wieso evtl. vor and und wieso in Klammern? Ererbter Fehler: Unerwartetes groß, oder? Positionssensitiv¶Das Wort ist signifikant in der Fehlermeldung, deswegen habe ich es als Zwischenüberschrift gewählt. Allerdings:
Ich nehme an die neue Meldung ist von einem aktuelleren Find.
Ich krieg ne Krise hier! Das ist so kein Arbeiten, Kinder! Macht mal Kehrwoche! ☺ Aber lustig. Was auch nervt, ist, dass das Wikidiff oft nachlässig wird, wenn es einen Unterschied beim Umbruch findet, und dann Unterschiede im Detail gar nicht mehr hervorhebt, was es sonst tut. Aber das gehört nicht hierher.
Ich würde die Unterstreichung tilgen. Und das war es auch schon - allerdings habe ich Dein neuestes Posting von 21:something noch nicht gelesen. |
||||||||
Anmeldungsdatum: Beiträge: 17552 Wohnort: Berlin |
Ja, arbeitet wie gewünscht, ist aber wg. der Fehlermeldung nicht optimal. Die Fehlermeldung bekäme man mit einem -depth zwar fort, aber dann würde das Hauptastarchiv die Archive in A und B nochmal einpacken. Die Manpage rät dringend zu -execdir und ich würde die Warnung auch gerne übernehmen, wenn ich ein Beispiel bei der Hand hätte, wo es kracht. Obwohl ich oft -exec nutze und mich nicht gegen -execdir sträuben will, habe ich leider kein gutes Beispiel, wo man es braucht. |