user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
In anderen Artikeln habe ich es bereits bekrittelt, ich weiß aber nicht was daraus geworden ist.
| find <Suchpfad> <-optionen>
|
Die Zeichen < und > dienen der Umleitung in der Shell, und sind als Markierungen für 'optional' daher m.E. ungeeignet. Wenn überhaupt gibt es den Quasi-Standard der manpages, der [eckige] Klammern verwendet. Aus man man: | Aufruf: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [Pfad...] [Suchkriterium]
|
Man sieht auch noch, dass es unvollständig ist. Ich meine dass das Gegenargument war, dass ein Buch von Markt&Technik oder Gallileo es so macht, und sogar 2-3 man pages in diesem Stil arbeiten. Aber was gar nicht geht ist ein '<-optionen>'. Entweder es geht um Optionen, dann groß und ohne Minus, weil ja jede einzelne ein Minus benötigt. Oder <-option>, mit 'option' als Platzhalter für die jeweilige Option.
liest foo ein und gibt das Gelesene nach bar aus. Dagegen wird mit eckigen Klammern sehr wahrscheinlich ein Fehler passieren der den User alarmiert:
| cat [foo] bar
cat: [foo]: No such file or directory
cat: bar: No such file or directory
|
Mein Vorschlag wäre sich an die man-Syntax zu halten; ich glaube bei eckigen Klammern kann weniger schief gehen. > | Die folgenden Konventionen gelten für den Abschnitt SYNTAX und können für andere Abschnitte als
Anleitung benutzt werden.
''' bold text ''' Literale Angaben wie in der Anzeige.
''italic text'' Ersetzen durch passendes Argument.
[-abc] Ein oder mehrere Argumente innerhalb der [ ] sind optional.
-a|-b Optionen, die durch | abgegrenzt sind, können nicht zusammen benutzt werden.
Argument ... Argument kann wiederholt werden.
[Ausdruck] ... gesamter Ausdruck innerhalb [ ] kann wiederholt werden.
|
Fett u. kursiv klappt aber in Kombination mit Syntaxtags schlecht, auch mit der Befehlsvorlage nicht:
find '''[-H] [-L] [-P] [-Olevel]''' [-D help|tree|search|stat|rates|opt|exec] [''Pfad''...]
(wie Sie sehen sehen Sie nichts). Soweit war das ist mehr Wiki-Allgemein und Inyoka-bezogen.
Hier ein paar Paare, oben Ist, darunter jeweils was ich als Soll vorschlage: Hinweisbox:
(da /media bzw. /mnt ein Unterverzeichnis von / ist), (da /media und /mnt Unterverzeichnisse von / sind),
ebenda:
Ob der User damit sparsam umgeht geht das Wiki nichts an, und daher kann eine Empfehlung unterbleiben. Es genügt der Hinweis, dass alle Laufwerke untersucht werden, und wie man es einschränkt. Im ganzen Block:
Hinweis:find durchsucht ebenfalls per Voreinstellung alle Unterverzeichnisse unterhalb des angegebenen Suchpfads. D.h. gibt man als Suchpfad / an, so werden alle Verzeichnisse inklusive aller eingehängten Laufwerke durchsucht (da /media bzw. /mnt ein Unterverzeichnis von / ist), was unter Umständen sehr lange dauern kann. Daher sollte man mit der Angabe von / als Suchpfad sparsam umgehen oder die Suche über ein Suchkriterium einschränken.
Hinweis:find durchsucht --ebenfalls per Voreinstellung-- alle Unterverzeichnisse --unterhalb-- des angegebenen Suchpfads. D.h. gibt man als Suchpfad / an, so werden alle Verzeichnisse inklusive aller eingehängten Laufwerke durchsucht (da /media bzw. /mnt ein Unterverzeichnis von / ist), was unter Umständen sehr lange dauern kann. Man kann die Suche aber über ein Kriterium einschränken.
Aus den Kriterien, oben: Es wird nach Dateien gesucht, die innerhalb der letzten n Minuten berührt wurden.
Wie berührt man eine Datei? Was heißt das? Rote Warnbox unten: Die Aktion "-exec" führt die Befehle ohne weitere Rückfragen aus, auch das Löschen von Dateien! Daher sollte man je nach gewünschter Aktion besser die Aktion "-ok " wählen.
Das ist unlogisch. Ob -ok besser ist oder nicht hängt nicht von der gewünschten Aktion ab, sondern davon, ob man sich vorher vergewissern will, und der User muss selbst wissen, was besser ist. Die Aktion "-exec" führt die Befehle ohne weitere Rückfragen aus, auch das Löschen von Dateien! Mit "-ok " statt "-exec" wird man für jede gefundene Datei gefragt, ob man die Aktion durchfürhen will.
Beispiele:
1. Im ersten Beispiel wird im Homeverzeichnis des Benutzer user nach der Datei einladung.txt gesucht: 1. Im ersten Beispiel wird im Homeverzeichnis des Benutzer user nach Dateien des Namens einladung.txt gesucht:
Ist die Datei nicht vorhanden, so erhält man keine Ausgabe, auch keine Fehlermeldung. Ist keine Datei vorhanden, so erhält man keine Ausgabe, auch keine Fehlermeldung.
Wie man sieht sind auch Wildcards * (genauso wie Joker ?) zur Suche erlaubt. In diesem Fall sollte der Suchbegriff auch von Anführungsstrichen " " eingeschlossen werden, um ein mögliche Fehlinterpretation des Suchbegriffs zu vermeiden. Der Befehl erzeugt z.B. folgende Ausgabe: Wie man sieht sind auch Wildcards * (genauso wie Joker ?) zur Suche erlaubt. Der Suchbegriff muss dann von Anführungsstrichen " " eingeschlossen werden, um eine vorzeitige Interpretation durch die Shell zu vermeiden. Der Befehl erzeugt z.B. folgende Ausgabe:
|
RapaNui
Anmeldungsdatum: 16. Juli 2007
Beiträge: 1925
Wohnort: Penco / Chile
|
Es grenzt was ab? Jetzt wird es albern! Was immer Du damit meinst; es gibt keinen Grund irgendwas abzugrenzen, selbst wenn das der Fall wäre, was ich bestreite.
Ok, ich werde albern, sieh es als Auflockerung des Themas. Es mag ein unglücklicher Satzaufbau sein, liegt wohl daran, dass ich schon zu lange aus Deutschland weg bin. Ich versuche mich zu bessern. Hier drehte es sich um die Lesbarkeit des Codes. Das ganze Thema dreht sich aber um das Quotieren in der Shell. Ja, wieso bringst Du denn Beispiele die Du selbst unsinnig findest?
Um zu zeigen das die Shell sehr wohl den Code interpretiert bevor es an das Unterprogramm weiterggegeben wird.
Ob es auch ohne "" funktioniert ist irrelevant auch ob ich einen Nanosekunde spare oder nicht ist unwichtig dabei. Bei {} handelt es sich um Anweisungen die in der Shell etwas bewirken, im Shellprogramm geschieht etwas was nicht sein muss/soll.
Was wäre, wenn man das in zukünftigen Updates zur Shell als Fehler ansieht und abfängt, vllt. nicht mehr weitergibt oder sogar die Shell beendet bevor find gestartet wird?
Das steht da, aber was bedeutet es? Dass die Shell die {} frisst bevor find sie verarbeitet, oder wenn find die Ergebnisse mit -exec ... {} verarbeitet?
Die Frage ist leicht zu beantworten, solange die Ausführung aus einer Shell heraus ausgeführt wird: Die Shell frisst die {} bevor find sie verarbeitet, da gibt es kein oder. Selbst der Aufruf des Programms find ist erst einmal Shellcode und wird interpretiert, das Ergebnis daraus ist: starte das Programm und gib all "den Schrott" dahinter, den den ich nicht kenne als Parameter mit.
Von daher ist Deine Aussage im ersten Teilsatz was dem -exec und seinen Partnern folgt, ist nicht Shellcode, und so werden auch viele Sachen, die in der Shell funktionieren nicht klappen.
falsch oder bedarf zumindest einer weiteren Verständnis-Erklärung, das viele Sachen nicht klappen kann nicht die Erklärung sein. find hat nichts mit der Shell zu tun und interpretiert deshalb auch nicht ihre Anweisungen, daher können sie nicht klappen.
? Vielleicht gibt es Konflikte mit einer anderen Shell?
Das könnte sein, wird aber durch generelles maskieren umgangen und ich muss es noch nicht einmal wissen. Es ist immer richtig und nicht nur manchmal.
Nein, das ist 'den Widersprüchen auf den Grund gehen' also ein kritisches Verfahren. Meist hat die manpage ja Recht, aber das muss nicht immer so sein.
Dem stimme ich zu, deshalb meine Erklärungsversuche.
'might need to be' heißt nicht 'sollte', sondern 'es könnte nötig sein', soweit mein Englisch reicht.
Mein Englisch ist miserabel, das gebe ich immer wieder zu, daher versuche ich den Kontext der Aussage zu verstehen und nicht die wörtliche Übersetzung. Wenn ich das mit 'es könnte nötig sein' einbaue, dann sähe es in etwa so aus:
Es könnte nötig sein, je nachdem welche Shell man benutzt, dass der Platzhalter "{}" und das Semikolon ";" quotiert/maskiert werden müssen.
Damit lasse ich den Leser wieder im unklaren - Muss ich oder muss ich nicht? Was sagt das Manual zur meiner Shell dazu? -, oder ich muss weitere Erklärungen dazu geben. Abgesehen davon, dass die wörtliche Übersetzung des 'Both of these constructions might need to be escaped' zu einen 'Es könnte sein das beide Konstruktionen ...' wird. Bei der Bash und der Dash, also bei Ubuntu-Standard, wissen wir aber, dass das Semikolon maskiert werden muss, 'Beide' wäre also falsch. Ein Artikel im Wiki soll keine komplette Programmablaufbeschreibung sein, also muss ich einen Kompromiss finden. Ein grundsätzliches Quotieren wird von allen Shells akzeptiert und nicht als Fehler ausgeworfen (bitte korrigiere mich, wenn nicht). Ein 'sollte' und 'muss' kommt dem mMn nahe, zumal es keine negativen, unerwünschten Auswirkungen hat. Nochmal, die Shell kennt die Anweisung {}, von daher ist es einfach sauberer diese grundsätzlich vor ihr zu verstecken. Sie hat damit nichts zu tun, sie soll sie unverändert weitergeben. Wenn man grundsätzlich so vorgeht vermeidet man Fehler und muss nicht immer überlegen: kann ich? soll ich? muss ich?
Da der Artikel noch nicht in der Baustelle ist kannst Du ihn ja noch nicht kritisch begutachten. Das Thema find ist schon Komplex genug und ich wollte diese Aussage (übrigens beim -exec Kommando in der man) nicht unterschlagen. Es soll Leute geben die neben dem Wiki auch die Manpage lesen 😉 und die könnten noch mehr verwirren.
Wen könnten die noch mehr verwirren? Könnten noch verwirrter sein? Verwirrter werden? Es könnten mehr Verwirrte werden? Ich kann gerade nicht folgen.
Das verwirrt mich jetzt, hier handelt es sich um einfache Rückbezüge, die im Deutschen gerne gebraucht werden. Oder war es schon wieder mein unmöglicher Satzbau? Egal, zur Klärung:
Die Maskierung fügt ein zusätzliches Gedöhns hinzu, von dem man wissen möchte, wozu es gut sein soll, und bisher wurde nicht gezeigt, wozu es gut sein könnte - also läßt man es weg. Es sei denn, man kann es doch zeigen. Ansonsten ist es ein Staubfänger, eine Christopherusplakette am Amaturenbrett, ein Glücksbringer-Voodoo; funktionslos, aber soll helfen.
Das hat nichts mit irgendwelchen religiösen Ansichten, Staubfängern oder Gedöns zu tun 😉, es geht um konsequente Benutzung einer Syntax, hier das Quotieren. Noch einmal, es hilft Fehler zu vermeiden. Wenn ich evtl. Fehlerquellen von vorne herein beseitige bzw. ausschließe, kann auch nichts schief gehen. Saludos, RapaNui
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
RapaNui schrieb: Es grenzt was ab? Jetzt wird es albern! Was immer Du damit meinst; es gibt keinen Grund irgendwas abzugrenzen, selbst wenn das der Fall wäre, was ich bestreite.
Ok, ich werde albern, sieh es als Auflockerung des Themas. Es mag ein unglücklicher Satzaufbau sein, liegt wohl daran, dass ich schon zu lange aus Deutschland weg bin. Ich versuche mich zu bessern. Hier drehte es sich um die Lesbarkeit des Codes.
Nein, Du willst irgendwas von etwas anderem abgrenzen, wenn ich Dich recht verstehe, aber es hat an der Stelle keinen Sinn etwas abzugrenzen - vielmehr will man ja den Platzhalter {} mit dem Kommando verbinden. Man möchte nicht abgrenzen.
Das ganze Thema dreht sich aber um das Quotieren in der Shell. Ja, wieso bringst Du denn Beispiele die Du selbst unsinnig findest?
Um zu zeigen das die Shell sehr wohl den Code interpretiert bevor es an das Unterprogramm weiterggegeben wird.
Das zeigst Du aber nicht, sondern Du zeigst, dass die Shell etwas ganz anderes interpretiert - das ist aber unstreitig.
Ob es auch ohne "" funktioniert ist irrelevant auch ob ich einen Nanosekunde spare oder nicht ist unwichtig dabei. Bei {} handelt es sich um Anweisungen die in der Shell etwas bewirken, im Shellprogramm geschieht etwas was nicht sein muss/soll.
Das stimmt eben weder für die bash:
noch für die dash:
| dash
$ {}
dash: {}: not found
|
Wenn Du aber eine Shell kennst, für die die Aussage stimmt, dass {} eine Anweisung ist, dann sag' es einfach.
Was wäre, wenn man das in zukünftigen Updates zur Shell als Fehler ansieht und abfängt, vllt. nicht mehr weitergibt oder sogar die Shell beendet bevor find gestartet wird?
Das ist jetzt kein ernstgemeintes Argument? Wenn morgen die Außerirdischen kommen und find mit ü schreiben - was dann?
Das steht da, aber was bedeutet es? Dass die Shell die {} frisst bevor find sie verarbeitet, oder wenn find die Ergebnisse mit -exec ... {} verarbeitet?
Die Frage ist leicht zu beantworten, solange die Ausführung aus einer Shell heraus ausgeführt wird: Die Shell frisst die {} bevor find sie verarbeitet, da gibt es kein oder.
Tut weder die bash, noch die dash, sondern das {} kommt heil bei find an.
Selbst der Aufruf des Programms find ist erst einmal Shellcode und wird interpretiert, das Ergebnis daraus ist: starte das Programm und gib all "den Schrott" dahinter, den den ich nicht kenne als Parameter mit.
Nein. Find ist kein Shellcode. Find ist ein Programm, welches man i.d.Regel aus einer Shell oder aus shellcode heraus aufruft - Du kannst es aber auch aus einem Javaprogramm, aus C, C++ und sicher ruby, python oder whatever aufrufen. Und zwar ohne eine Shell zwischenzuschalten. Find ist ja kein Shellinterna, sondern ein eigenständiges Programm. Du kannst auch aus zenity u.dgl. find aufrufen.
Von daher ist Deine Aussage im ersten Teilsatz was dem -exec und seinen Partnern folgt, ist nicht Shellcode, und so werden auch viele Sachen, die in der Shell funktionieren nicht klappen.
falsch
Falsch. Es ist nicht falsch, es ist vielmehr richtig.
? Vielleicht gibt es Konflikte mit einer anderen Shell?
Das könnte sein, wird aber durch generelles maskieren umgangen und ich muss es noch nicht einmal wissen. Es ist immer richtig und nicht nur manchmal.
Immer richtig ist natürlich praktisch, nur bisher hast Du kein einziges Beispiel gezeigt, in dem es nützlich ist - Du hast nur Beispiele gebracht, in denen es nicht schädlich war. Ebensogut kannst Du 2 oder 3 Leerstellen verlangen, übrigens passenderweise vielleicht mit dem Argument der stärkeren Abgrenzung. Wie kannst Du denn denken, dass doppelte Anführungsstriche für alle Shells, die Du nicht kennst, richtig sind, und nicht dort vielleicht etwas anderes bedeuten o. bewirken?
Nein, das ist 'den Widersprüchen auf den Grund gehen' also ein kritisches Verfahren. Meist hat die manpage ja Recht, aber das muss nicht immer so sein.
Dem stimme ich zu, deshalb meine Erklärungsversuche.
Du erklärst aber nichts, sondern versuchst zu erraten, und verkaufst das als Wahrheit.
'might need to be' heißt nicht 'sollte', sondern 'es könnte nötig sein', soweit mein Englisch reicht.
Mein Englisch ist miserabel, das gebe ich immer wieder zu, daher versuche ich den Kontext der Aussage zu verstehen und nicht die wörtliche Übersetzung. Wenn ich das mit 'es könnte nötig sein' einbaue, dann sähe es in etwa so aus:
Es könnte nötig sein, je nachdem welche Shell man benutzt, dass der Platzhalter "{}" und das Semikolon ";" quotiert/maskiert werden müssen.
Damit lasse ich den Leser wieder im unklaren - Muss ich oder muss ich nicht? Was sagt das Manual zur meiner Shell dazu? -, oder ich muss weitere Erklärungen dazu geben. Abgesehen davon, dass die wörtliche Übersetzung des 'Both of these constructions might need to be escaped' zu einen 'Es könnte sein das beide Konstruktionen ...' wird. Bei der Bash und der Dash, also bei Ubuntu-Standard, wissen wir aber, dass das Semikolon maskiert werden muss, 'Beide' wäre also falsch. Ein Artikel im Wiki soll keine komplette Programmablaufbeschreibung sein, also muss ich einen Kompromiss finden. Ein grundsätzliches Quotieren wird von allen Shells akzeptiert und nicht als Fehler ausgeworfen (bitte korrigiere mich, wenn nicht). Ein 'sollte' und 'muss' kommt dem mMn nahe, zumal es keine negativen, unerwünschten Auswirkungen hat.
Du kannst auch, wie gesagt, behaupten, man müsse alle Optionen mit 2 Blanks voneinander trennen. Da dürfte es ähnlich schwierig sein ein Gegenbeispiel zu finden, ein Beispiel, wo es schadet. Wer will kann natürlich jederzeit den Quellcode von bash, dash oder wasimmer sich besorgen, und absichtsvoll dafür sorgen, dass es scheitert oder dass es scheitert wenn nicht. Es ist eben ein Phänomen der jeweiligen Shell, und nicht von find, und daher hat es im Findartikel nichts verloren. Außerdem ist es zwar so, dass bash und dash das Semikolon maskieren müssen, und es daher ein hilfreicher Hinweis in der manpage der Shell ist, aber wenn Du mit Alt-F2 in xubuntu ein Kommandofenster öffnest, dann brauchst Du darin keine Maskierung.
Nochmal, die Shell kennt die Anweisung {}, von daher ist es einfach sauberer diese grundsätzlich vor ihr zu verstecken.
Bitte, dann führe den Nachweis, dass eine - nicht die Shell {} für eine Anweisung hält. Du hast es jetzt wiederholt, und weder eine Quelle dafür angegeben, noch ein Indiz - es ist die schiere Behauptung.
Sie hat damit nichts zu tun, sie soll sie unverändert weitergeben. Wenn man grundsätzlich so vorgeht vermeidet man Fehler und muss nicht immer überlegen: kann ich? soll ich? muss ich?
Nein. Du verläßt Dich in Deinen ganzen Ausführungen auf eine falsche Idee davon, wie find funktioniert, was find mit der Shell zu tun hat, und wie eine Maskierung funktioniert. Wenn man grundsätzlich so wie Du vorgehst - entschuldige bitte etwaige Verletzungen - dann verfestigen sich falsche Modelle von der Realität zu Gewißheiten, und es entsteht ein Cargo-Cult.
Da der Artikel noch nicht in der Baustelle ist kannst Du ihn ja noch nicht kritisch begutachten. Das Thema find ist schon Komplex genug und ich wollte diese Aussage (übrigens beim -exec Kommando in der man) nicht unterschlagen. Es soll Leute geben die neben dem Wiki auch die Manpage lesen 😉 und die könnten noch mehr verwirren.
Wen könnten die noch mehr verwirren? Könnten noch verwirrter sein? Verwirrter werden? Es könnten mehr Verwirrte werden? Ich kann gerade nicht folgen.
Das verwirrt mich jetzt, hier handelt es sich um einfache Rückbezüge, die im Deutschen gerne gebraucht werden. Oder war es schon wieder mein unmöglicher Satzbau? Egal, zur Klärung:
Verwirren ist aber aktiv: Ich kann Dich verwirren, oder durch Dich verwirrt werden - Du meinst doch hier die Leute könnten verwirrt werden, oder?
Die Maskierung fügt ein zusätzliches Gedöhns hinzu, von dem man wissen möchte, wozu es gut sein soll, und bisher wurde nicht gezeigt, wozu es gut sein könnte - also läßt man es weg. Es sei denn, man kann es doch zeigen. Ansonsten ist es ein Staubfänger, eine Christopherusplakette am Amaturenbrett, ein Glücksbringer-Voodoo; funktionslos, aber soll helfen.
Das hat nichts mit irgendwelchen religiösen Ansichten, Staubfängern oder Gedöns zu tun 😉, es geht um konsequente Benutzung einer Syntax, hier das Quotieren. Noch einmal, es hilft Fehler zu vermeiden. Wenn ich evtl. Fehlerquellen von vorne herein beseitige bzw. ausschließe, kann auch nichts schief gehen.
Fragt sich welche Fehlerquelle Du vermeidest. Es ist ja im Gegenteil so, dass den Leuten eine Notwendigkeit suggeriert wird, die keine ist, d.h. wer diese Anführungsstriche hinterfragt, der wird wird sich etwas doof vorkommen, weil er einfach nicht rausfindet, wozu die Anführungsstriche gut sind. In der Folge wird er den Anfürhungsstrichen also auch an den Stellen mistrauen, an denen sie nötig sind, und dann zu Unrecht.
|
RapaNui
Anmeldungsdatum: 16. Juli 2007
Beiträge: 1925
Wohnort: Penco / Chile
|
So, ich habe den Artikel komplett überarbeitet und erst jetzt Online gestellt, d.h. es ist komplett neuer Text und die Anmerkungen von user unknown trafen auf den alten unbearbeiteten Artikel zu. Die Anmerkung zu den Optionen hatte ich teilweise schon so eingebaut, wie er es vorschlägt. Ich pers. tendiere jedoch zu Optionen groß mit Minus, da es so bei einem 'Befehl --help' angezeigt wird, wäre aber jederzeit änderbar. Der Rest seiner Anmerkungen betraf mich noch nicht, aber ab jetzt. Hintergrund meiner Vorgehensweise: Der Artikel wurde mehr aufgegliedert, er soll leichter zu ablauffähigen find -Anweisungen führen.
Ich habe den Optionen eigene Bezeichnungen gegeben und diese als Abschnittsüberschriften genutzt. Auch hier schreibe ich diese Optionen komplett groß (wg. dem Zusammenhang), sollte das nicht gewünscht sein - kann man ändern. Es kann gut sein, dass ich zu sehr gestrafft habe und die Aussagen nicht mehr eindeutig sind. Darum bitte ich gesondert darauf zu achten. Alternativen, z.B. -iname und -name, habe ich in Klammern hinter die Beschreibungen gesetzt. Verwirrt das? Wie könnte man das besser machen?
Saludos, RapaNui Edit: P.S. Ich habe die unsäglichen '' entnommen, aber das Semikolon maskiert belassen. OT und Antwort zum vorletzen Post: In der Frage der Maskierung kommen wir nicht weiter. Entweder Du verstehst wirklich nicht worauf ich hinaus will, oder es macht Dir einfach nur Spass alles in Frage zu stellen. Du antwortest mir irgend etwas mit Außerirdischen und willst mich so anscheinend als lächerlich hinstellen. Du antwortest mit einem Alt-F2 unter xubuntu obwohl ich über die bash oder die dash schreibe. Was bewirkt Alt-F2? Welches Programm steckt dahinter? Das Ganze geht mittlerweile total am Artikel find vorbei und hat mMn hier nichts mehr zu suchen. Das hier: Es ist eben ein Phänomen der jeweiligen Shell, und nicht von find, und daher hat es im Findartikel nichts verloren.
Außerdem ist es zwar so, dass bash und dash das Semikolon maskieren müssen, und es daher ein hilfreicher Hinweis in der manpage der Shell ist, aber wenn Du mit Alt-F2 in xubuntu ein Kommandofenster öffnest, dann brauchst Du darin keine Maskierung.
verstehe ich so, dass Du selbst das Maskieren des Semikolons aus dem Wiki streichen möchtest. Ich kann mir sehr gut vorstellen das Du wesentlich mehr von der ganzen Materie verstehst als ich oder sonst wer hier. Aber, wir befinden uns in einem Hilfeforum mit angeschlossenem Wiki. Beides ist vorrangig an unerfahrene Ubuntu-Anwender gerichtet, oder liege ich da schon wieder falsch? Hinweise vorzuenthalten, die auch noch in der Manpage stehen, und damit bewußt in Kauf zu nehmen das der Leser auf die Schnautze fällt find ich nicht fair. Das Ganze läuft mir zu sehr auf "Du dummer Benutzer, frag mich doch ich weiß es besser" hinaus. Jmd. der die Manpages ließt und auch versteht braucht idR kein Wiki, dann können wir auch die Überarbeitung von find fallen lassen.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Ich fühle mich düpiert und bin richtiggehend sauer. Du kritisierst meinen Absatz als falsch, und diskutierst stundenlang, und im Hintergrund schreibst Du einen Artikel, in dem der Absatz gar nicht vorkommt? Du kündigst eine Überarbeitung an, und dann erzeugst Du quasi einen komplett neuen Artikel? Dann kritisiere ich doch nicht vorher einen einzelnen Satz, der im neuen Artikel gar nicht mehr drin ist. Ich habe mir die Zeit genommen den ganzen Text nochmal durchzulesen und mir Gedanken zu machen, und dann ziehst Du wie ein Zauber das Kaninchen einen gänzlich neuen Text hervor. Wir hatten vorher auch schon Arbeit in den Text gesteckt - daher finde ich diese gründliche Überarbeitung ohne vorherige Kritik auch respektlos gegenüber dieser Vorleistung. Es ist ja nicht so, dass find selbst einer größeren Neuerung unterzogen worden wäre, die so eine Umarbeitung dringend nötig macht. Ich haber mir heute früh, schon sehr verstimmt, den neuen Artikel durchgelesen, und beschlossen nach ein paar Stunden nochmal zu prüfen, ob mein erster Eindruck so bleibt, oder ob es vielleicht nur am ersten Ärger liegt, dass ich den als eine derartige Katastrophe empfinde. Wieso soll ich jetzt Deinen Artikel kritisieren, wenn in 3 Tagen jmd. anderes kommt, und ohne Diskussion Deine Arbeit in die Tonne tritt, und mit einem neuen Versuch herumkommt? Bevor ich Deinen Beitrag näher beleuchte drängt es mich aber auf Deine jüngsten Edits hier einzugehen.
In der Frage der Maskierung kommen wir nicht weiter. Entweder Du verstehst wirklich nicht worauf ich hinaus will, oder es macht Dir einfach nur Spass alles in Frage zu stellen. Du antwortest mir irgend etwas mit Außerirdischen und willst mich so anscheinend als lächerlich hinstellen. Du antwortest mit einem Alt-F2 unter xubuntu obwohl ich über die bash oder die dash schreibe. Was bewirkt Alt-F2? Welches Programm steckt dahinter? Das Ganze geht mittlerweile total am Artikel find vorbei und hat mMn hier nichts mehr zu suchen.
Wenn Du im Wiki nach "Alt+F2" suchsts findest Du, dass es auch unter KDE und Gnome Programme gibt, um ein einzelnes Kommando auszufürhen. Und darin bedarf das Semikolon keiner Maskierung, und es soll Dir zeigen, dass man find eben nicht nur, wie von Dir behauptet, aus der Shell aufrufen kann. Wir wollen aber mal festhalten, dass nicht ich Deinen, sondern Du meinen Text kritisiert hast, d.h. es wäre an Dir zu zeigen, was an meinem Hinweis falsch ist. Das konntest Du nicht zeigen, und jetzt versuchst Du es so darzustellen, als sei mein Hinweis nur für Experten nachvollziehbar. Wieder hast Du keinen Beleg. Es ist ja im Gegenteil so, dass das Weglassen von Anführungsstrichen ja wohl einfacher ist als das setzen - wieso soll sich der User merken, diese zu setzen, wenn es keinen Effekt hat? Für den Anfänger ist es natürlich einfacher, wenn er nicht mit sinnlosen Dekorationen um sich zu werfen ermuntert wird.
verstehe ich so, dass Du selbst das Maskieren des Semikolons aus dem Wiki streichen möchtest.
Verstehst Du falsch. Wenn ich etwas hätte streichen wollen, dann hätte ich das gesagt, weil ich wenig Hemmungen habe zu sagen was ich meine, wenn es der Klarheit dient und das diplomatische Undeutlichkeiten nicht mein Geschäft sind.
Ein Artikel im Wiki soll keine komplette Programmablaufbeschreibung sein, also muss ich einen Kompromiss finden.
In Fragen der Wahrheit gibt es keinen Kompromiss. Wenn etwas immer gemacht werden muss schreibt man immer und wenn es Ausnahmen gibt schreibt man meist. Den Unterschied lernt man als 5jähriger. Das Wiki muss immer versuchen wahr zu bleiben, auch in der Vereinfachung, sonst ist es wertlos. Wenn Du das anders siehst, dann werden wir noch viel Freude miteinander haben.
Hinweise vorzuenthalten, die auch noch in der Manpage stehen, und damit bewußt in Kauf zu nehmen das der Leser auf die Schnautze fällt find ich nicht fair.
Hier drehst Du wieder um. Nachdem Dir misslungen ist zu zeigen, dass der User in irgendeiner Situation auf die Schnauze fallen könnte berufst Du Dich wieder auf die manpage, als hätte ich nicht en detail dargestellt, was meine Kritik daran ist. Du mußt dann zurückblättern und meine Kritik erneut lesen, wenn ich hier die anderen Leser nicht langweilen soll. Ich habe auch keine Lust mich zu wiederholen.
Das Ganze läuft mir zu sehr auf "Du dummer Benutzer, frag mich doch ich weiß es besser" hinaus.
Inwiefern? Mir läuft Dein Text auf ein "Du dummer Benutzer, frag mich nicht, ich weiß es besser, also tu was ich sage und halt den Mund" hinaus. Du stellst Dich keiner Kritik, Du gibst keine Argumente, Du weichst aus, wenn man Dich festnagelt, und stellst Dich doof.
Jmd. der die Manpages ließt und auch versteht braucht idR kein Wiki, dann können wir auch die Überarbeitung von find fallen lassen.
Jmd. der die Manpages ließt und auch versteht braucht idR kein Wiki, dann brauchen wir uns auch nicht darum zu sorgen, wenn das Wiki im Punkt der Maskierung von der manpage abweicht. Deine Argumentation ist nicht stringent, sie ist nicht logisch, und Du diffamierst mich als arrogant. Was an Deinem neuen Artikel katastrophal ist werde ich in einem gesonderten Posting darlegen.
|
RapaNui
Anmeldungsdatum: 16. Juli 2007
Beiträge: 1925
Wohnort: Penco / Chile
|
user unknown schrieb: Ich fühle mich düpiert und bin richtiggehend sauer. Du kritisierst meinen Absatz als falsch, und diskutierst stundenlang, und im Hintergrund schreibst Du einen Artikel, in dem der Absatz gar nicht vorkommt? Du kündigst eine Überarbeitung an, und dann erzeugst Du quasi einen komplett neuen Artikel? Dann kritisiere ich doch nicht vorher einen einzelnen Satz, der im neuen Artikel gar nicht mehr drin ist. Ich habe mir die Zeit genommen den ganzen Text nochmal durchzulesen und mir Gedanken zu machen, und dann ziehst Du wie ein Zauber das Kaninchen einen gänzlich neuen Text hervor. Wir hatten vorher auch schon Arbeit in den Text gesteckt - daher finde ich diese gründliche Überarbeitung ohne vorherige Kritik auch respektlos gegenüber dieser Vorleistung. Es ist ja nicht so, dass find selbst einer größeren Neuerung unterzogen worden wäre, die so eine Umarbeitung dringend nötig macht.
So jetzt reicht es mir weiter lese ich nicht mehr. Ich zitiere Judith Holofernes: "Ich glaube, es hackt” Du verlangst jetzt auch noch von mir, dass ich 24 Stunden Online bin, nur damit Du, wenn es Dir gerade passt, den neuen/geänderten Artikel lesen kannst? Wie meinem Profil zu entnehmen ist Wohnort:Penco / Chile (ich meine jetzt das Teil links von diesem Text, dort wo auch mein Nick steht) lebe ich auf einem anderen Kontinent. Jeder Kind lernt, dass es auf der Welt Zeitzonen und Zeitverschiebungen gibt. Nenn mir bitte einen vernüftigen Grund warum ich innerhalb von 2:32h nach dem verschieben schon aktiv werden muss. Wir hatten zu Deiner Antworzeit (21:41 deutsche Zeit) hier erst 17:41 CLST und es soll tasächlich noch Leute geben die einer geregelten Arbeit nachgehen – Ach nein, vergiss es, Du stellst ja alles in Frage und glaubst dem ja sowieso nicht. Schon im 2. Post von mir schriebe ich: "Eigentlich auf das: Soll ich den Hinweis im Artikel aufnehmen oder nicht, darum geht es mir, z.Zt. sieht das in meiner Offline-Version so aus:" Du bist doch so weise, dann sollte Dir auch der Begriff OFFLINE etwas sagen. Die Regel bei uu.de schreiben vor das ich bei grundlegenden Änderungen über die Baustelle gehen muss, das habe ich beantragt. In der Einleitung zu meinem allerersten Post (4. Satz) habe ich geschrieben: "Meine Idee ist etwas aufwendiger um es im orig. Artikel zu ändern, bitte in die Baustelle". Bei 'Idee' und 'aufwendiger' sollte jedem klar sein, dass ich im Artikel nicht nur kleine Änderungen vornehmen werde. Jetzt muss ich, auch wenn ich es nicht wollte noch etwas zu Deinen ganzen Ausführungen hier sagen:
Du hast bis jetzt nicht den Beweis erbracht, dass die Shell das Konstrukt nicht interpretiert. Dein {} in der Shell zeigt nur, dass das Konstrukt (leer) so weitergegeben wird und die Shell meldet 'command not found', es beweist aber nicht, dass es für die Shell keine Bedeutung hat. Das macht sie übrigens auch bei der Eingabe von $, nach Deinen Rückschlüssen hat das Dollarzeichen also auch keine Bedeutung in der Shell. Meine Anweisung, hier nochmal mit echo echo {1,2} zeigt zumindest das etwas in der Shell passiert und dazu brauche ich keinen Quellcode lesen. Das normale Manual z.B. zur Bash sagt mir, dass es sich bei {} um brace expansion handelt, auch dafür brauche ich keinen Quellcode. Deinen Hinweis auf die Manpages und dass man ihnen nicht uneingeschränkt glauben kann (da sie fehlerhaft sein können, fehlerhaft sind) habe ich akzeptiert, dennoch kann ich nicht generell in Frage stellen was dort geschrieben. Dann darf ich keinem mehr trauen, auch Deinen Antworten in den Hilfeforen nicht. Wenn ich so wie Du vorgehe und jedes Wort auf die Goldwaage lege, dann präzesiere ich bei meine Aussage: Dein Das, was dem -exec und seinen Partnern folgt, ist nicht Shellcode, und so werden auch viele Sachen, die in der Shell funtkionieren nicht klappen.
ist genauso unnütz im Artikel. Du redest von Shellcode und meinst Shellanweisungen. Das Wort Shell kann man generalisieren zu Programm und jetzt haben wir Programmcode und das ist wiederum Quellcode. Ein normaler Anwender wird niemals Quellcode in der Shell eingeben. Man kann auch die Wikipedia dazu befragen: Shellcode und es wiederrum in Frage stellen, da wikipedia ja fehlerbehaftet ist. Deine ganze Argumentation beruht darauf mich als dumm und lächerlich hinzustellen. Du antwortest mir mit religiösem oder Voodoo-Gefasel, benutzt Gedöns oder schreibst von Außerirdischen die find mit ü schreiben wollen. Du willst mich im Deutschen korrigieren, obwohl ich darauf hingewiesen habe, dass ich in dieser Sprache nicht zu Hause bin. Du suggerierst sogar, dass die Shell fertigt programmiert ist, dort keine Veränderungen mehr vorgenommen werden und nur ich, der Dumme, auf die Idee kommen könnte eine leere 'brace expansion' als Fehler auszuwerfen. Nochmals mit anderen Worten: Unabhängig davon, dass Du in Teilen wahrscheinlich Recht hast, zumindest dass ein {} ohne Quotierung z.Zt. nichts falsch macht. Deine Strategie ist darauf ausgelegt Dein Gegenüber (also mich) anzugreifen und als komplett unwissend darzustellen. Du greifst pers. an, was ich nie getan habe und Du benutzt eine Strategie, die religiöse Eiferer aller Coleur seit Jahrhunderten benutzen. Deine Aussage Wir hatten vorher auch schon Arbeit in den Text gesteckt...
beweist nochmals, dass Du es nicht erträgst wenn irgendetwas von Dir (wir schließt Dich ja mit ein) in Frage gestellt wird. Du bist eben unfehlbar und daran möchte ich nicht rütteln. Das ist alles menschlich, hat aber absolut garnichts mit Ubuntu und "Menschlichkeit gegenüber Anderen" zu tun, Du bist eben wie Du bist. Zu meinem Vorschlag gab es eine Vorlage, die genau so vorging wie ich es umgesetzt habe. Diese Vorlage stammt aus Schulungsveranstaltungen zur Bash und hier bes. zu find. Da es aber nicht der Norm von user unknown entspricht verabschiede ich mich mit: Es ist ein Wiki, also macht damit was ihr wollt oder für richtig befindet, ich, für meinen Teil, beantrage den Baustellenartikel zu löschen, da, wie von user unknown dargelegt, als Blödsinn anzusehen ist. Ich verbleibe MfG und Xau Ponga toda la wea bajo tu prepucio y sea feliz.
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29046
Wohnort: WW
|
Hallo, @RapaNui: Es ist ein Wiki, also macht damit was ihr wollt oder für richtig befindet, ich, für meinen Teil, beantrage den Baustellenartikel zu löschen,
Im Ernst? Inhaltlich ist der Artikel IMHO besser, allerdings hätte ich noch ein paar Vorschläge für Optimierungen bzgl. der Struktur... Gruß, noisefloor
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
noisefloor schrieb: Hallo, @RapaNui: Es ist ein Wiki, also macht damit was ihr wollt oder für richtig befindet, ich, für meinen Teil, beantrage den Baustellenartikel zu löschen,
Im Ernst? Inhaltlich ist der Artikel IMHO besser, allerdings hätte ich noch ein paar Vorschläge für Optimierungen bzgl. der Struktur...
Der Artikel ist in vielerlei Hinsicht ein enormer Rückschritt. Insbesondere das angebliche Hauptziel für Anfänger verständlicher zu sein wird m.E. großartig verfehlt. Meine Hauptkritik, auf wenige Sätze konzentriert:
Niemand nennt Dateien und Verzeichnisse 'Archive', ausser es handelt sich um Tar-Archive (tar:= tape archive). Aber im Gegenteil ist unter Linux alles eine Datei, auch ein Verzeichnis. Es werden weitere, private Benennungen benutzt, als ob diese gängige Ausdrücke seien, die aber sonst niemand benutzt, wie 'Suchpfad' und Ungetüme wie 'eine eig. /home-Hauptverzeichnis'. Unvollständige und unverständliche Sätze wie
-depth: Start der Ausführung ein Verzeichnis vorher, entspricht einem "SUCHPFAD-1".
Didaktisch ist das Pferd von hinten aufgezäumt. Statt einfach und einladend zu beginnen wird der User erst mit einer sperrigen Nomenklatur behelligt, die nur in diesem, einen Wikiartikel gültig wäre (sagt nicht, im ganzen Wiki werde jetzt 'Datei' und 'Verzeichnis' durch 'Archiv' ersetzt), Dann kommen die Symlinks, die kein Mensch je braucht. Dann der unsägliche, sogenannte Suchpfad - ein Begriff der quer zu allen anderen Begriffen von Pfad (PATH, LD_LIBRARY_PATH, MANPATH, CLASSPATH) verwendet wird, und der, wenn überhaupt, in die Shell gehört, und nichts mit find zu tun hat. Dann kommen wieder zwei Kästen die sich mit -P -H und -L beschäftigen. Spätestens hier ist sowieso niemand mehr da. Es kommen aber weitere Blöcke, Tabellen, Hinweis- und Warnboxen, und noch eine Tabelle, und dann kommt zum ersten Mal, kurz vor Ende der Seite, ein lesbares Beispiel. Das ist im Orginalartikel auch nicht optimal, und ich wäre bereit den zu überarbeiten, aber da kann man wenigstens die Texte verwenden, und es ist nicht permanent von Archiven die Rede. Das Angebot die Baustelle zu löschen würde ich unbürokratisch aufnehmen.
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29046
Wohnort: WW
|
Hallo, der erste Teil nach der Einleitung ist in der Tat der, den auch ich umstellen würde... Gruß, noisefloor
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
RapaNui schrieb: Deine ganze Argumentation beruht darauf mich als dumm und lächerlich hinzustellen.
Nein, ganz und gar nicht. Du selbst hast Dich leider in diese Position reinmanövriert, aber nicht aus Dummheit, sondern aus Sturheit. Stur bin ich zwar auch, aber da ich im aktuellen Disput Recht hatte hat es mir nicht geschadet. Du hast wahrscheinlich der Manpage, Tutorials die auf der Manpage und einer oberflächlichen Interpretation der manpage beruhen, oder einem veralteten Wissen, und damit meine ich etwas in der Größenordnung von ca. 20 Jahren, nicht 5-10 Jahren, beruht, welches nicht aktualisiert wurde, und unkritisch von Generation zu Generation gegeben wurde. Die Gnu-utils werden nicht nur auf Ubuntu/Linux, sondern auf verschiedenen Unixen eingesetzt. Und diese anderen Unixe haben andere Shells im Einsatz. Je weiter Du in der Historie zurückgehst während Du gleichzeitig von Linux weg gehst, umso eher magst Du eine Unixshell finden, die {} interpretiert. Wenn Du eine findest, sag bitte Bescheid - es interessiert mich immer noch, ob es wirklich noch eine gibt. Denn es gibt da ja diese POSIX-Bestrebung die Dinge ein wenig zu vereinheitlichen. Also die Manpage warnt lediglich davor, dass es Shells geben könnte, die es erforderlich machen, das {} zu maskieren - das ist aber wie gesagt keine für Linux zugeschnittene Warnung, und berechtigt, als gnu-find eben plattformneutral ist. Aber unser Wiki ist nicht plattformneutral. Und so kommt es, dass die Manpage und ich gleichzeitig Recht haben können, eine Möglichkeit, die Du zu früh ausgeschlossen hast. Erst hast Du mit der Autorität der Manpage versucht zu argumentieren, und ich habe Dir exemplarisch vorgeführt - ich würde sagen bewiesen, dass Du falsch liegst. Bis dahin war es unproblematisch, aber dann fingst Du an mit der Phantasie von zukünftigen Shells zu kommen, die es anders machen. Du musst wohl selbst in der Shell zu prüfen begonnen haben, was es mit den {} auf sich hat, und kamst zu bemerkenswerten Ergebnissen mit {1,2}, aber eben leider nicht mit {}. Dennoch hast Du versucht, und versuchst immer noch mit dem Unsinn (Deine Worte) irgendwelche Punkte zu machen, statt aufrichtig einzuräumen, dass da kein Gras wächst. Jetzt habe ich das zurückgewiesen und mir nicht andrehen lassen, und jetzt kommst Du mit dem $. Was soll das? Was glaubst Du denn damit beweisen zu können?
Dein {} in der Shell zeigt nur, dass das Konstrukt (leer) so weitergegeben wird und die Shell meldet 'command not found', es beweist aber nicht, dass es für die Shell keine Bedeutung hat.
Doch, genau das wird damit bewiesen: Es hat keine Bedeutung:
| blafasel
blafasel: command not found
|
Glaubst Du die Shell hat einen geheimen Interpretationsvorbehalt, der eine halbe Stunde später dann um die Ecke schaut? Laß einfach mal die Idee an Dich ran, daß {} für die Shell keine Bedeutung hat ...
| ibmux:~/daten/images > {}
{}: command not found
ibmux:~/daten/images > "{}"
{}: command not found
ibmux:~/daten/images > '{}'
{}: command not found
|
... obwohl {1,2} eine Bedeutung hat.
Du willst mich im Deutschen korrigieren, obwohl ich darauf hingewiesen habe, dass ich in dieser Sprache nicht zu Hause bin.
Dafür ist Dein Deutsch schon sehr gut, alle Achtung, aber für Wikiartikel reicht es dann letztlich vielleicht nicht, weil diese soviele unterschiedliche Kriterien erfüllen müssen: Möglichst knapp sein, möglichst einfach verständlich, dennoch präzise, in erster Linie wahr, dem Jargon aber entsprechend, und dabei wirken, als sei das alles ganz leicht.
Du suggerierst sogar, dass die Shell fertigt programmiert ist, dort keine Veränderungen mehr vorgenommen werden und nur ich, der Dumme, auf die Idee kommen könnte eine leere 'brace expansion' als Fehler auszuwerfen.
Nein, und ich finde es extrem unlauter wenn Du das Argument wieder auspackst, obwohl ich es behandelt habe, so als ob Du mein Gegenargument mit dem ü nicht verstanden hättest. Das kaufe ich Dir nicht ganz ab, und habe daher das Gefühl Du willst mich nur ärgern, mir nur die Arbeit bereiten das nochmal zu erklären, und so vom eigentlichen Thema abzulenken, und mich auf Nebenschauplätze von Kleinigkeiten zu leiten. Dein logischer Fehler, die argumentative Unredlichkeit, sagen wir Dein Trick besteht darin, die Ungewissheit der Zukunft so auszudeuten, als sei sie für Dich weniger ungewiss, als könne sich, wenn sich was ändert, nur zu Deinen Gunsten ändern. Es ist wie der Fußballer, der 2x die Latte trifft, und sich beim Schicksal beschwert, dass doch nur wenige Zentimeter gefehlt hätten, und der Ball wäre ins Tor gefallen. Ja - aber wenn nur wenigige Zentimeter in die andere Richtung gefehlt hätten, dann wäre der Ball nichtmals an die Latte gegangen, sondern ein Stück über das Tor hinweg. Und mit einer irgendwie gearteten möglichen Änderung der Zukunft kannst Du alles begründen. Es kann dann ebensogut verboten werden geschweifte Klammern zu maskieren - das liegt genauso fern oder nah. Und ich werde sauer wenn ich mit so blöden Argumenten beschäftigt werden, die ja gewiß nicht am Anfang Deiner Überlegung standen, sondern die Du jetzt hinterher auspackst, als Ausrede irgendwie nachschiebst. Das ist so ermüdend. Das ist so weit unter unser beider Niveau. Es ist nur ein rituelles Abklatschen dieses rhetorischen Schnörkels, den man sich sparen könnte, wenn man nicht darauf aus wäre um jeden Preis Recht zu behalten, sondern zu sehen, was wahr ist, und was falsch, und nichts weiter. Aber leider sieht man dieses Argumentationsmuster immer wieder, und Du bist nicht der Einzige der so argumentiert, und daher nehme ich mir mal die Zeit dieses ganze Muster auseinanderzupflücken - nimm es nicht persönlich!
Wenn ich so wie Du vorgehe und jedes Wort auf die Goldwaage lege, dann präzesiere ich bei meine Aussage: Dein
Das, was dem -exec und seinen Partnern folgt, ist nicht Shellcode, und so werden auch viele Sachen, die in der Shell funtkionieren nicht klappen.
ist genauso unnütz im Artikel. Du redest von Shellcode und meinst Shellanweisungen.
Das ist wirklich kein gelungener Satz, den kritisierst Du zurecht, und jetzt, nach unserem längeren Ausflug in die möglichen Auslegungen von Sätzen könnte ich den auch besser fassen. Aus diversen Supportaktivitäten und eigenen Erfahrungen kann ich sagen, dass ich nicht der einzige bin, dem leicht der Kopf rauscht, und der unsicher wird, wer wann was von einem Befehl interpretiert und nicht interpretiert, wann etwas maskiert werden muss und wann nicht. Wenn 3 Programme involviert sind, und das ist bei find -exec ja i.d.R. der Fall, wird es schwierig. Man sieht beispielsweise derartiges:
| find -name "prof*" -exec grep uid {} | grep max \;
|
aber das Pipecommando funktioniert nicht in find; es ist kein Shellcode, der dem exec folgt, das wollte ich ausdrücken. Das ist aber nicht gelungen; es würde zumindest ein Beispiel wie dieses erfordern. Man kann natürlich auch Shellcode verwenden, aber den muß man dann explizit der Shell übergeben, und dann kommen auch Quotierungsaspekte ins Spiel:
| find ~ -maxdepth 3 -type d -name "U*" -exec bash -c 'ls -d "{}"' \;
|
Und jetzt kommt der Clou: Sofern man immer nur Beispiele zu sehen bekommt, in denen maskiert wird, was maskiert werden muss, und nicht maskiert wird, was nicht maskiert werden muss, kann man deduzieren, wie das alles funktioniert - man kann ein Modell davon bilden, wie das abläuft, und an den Maskierungen ablesen, ob das Modell stimmt. Und überflüssiges Gekröse in Form unsinniger Anführungsstriche behindert ein solches Verständnis, und leitet die Leute auf die falsche Fährte. Man bringt ihnen damit eine Art Cargocult-Programmierung bei. Oder Waschzwang.
Du greifst pers. an, was ich nie getan habe
So? Wo habe ich das getan? Du schreibst zwar ständig, ich würde Dich als dumm hinstellen, aber ich habe nichts dergleichen getan. Zeig mir, wo ich Dich persönlich angegriffen habe.
und Du benutzt eine Strategie, die religiöse Eiferer aller Coleur seit Jahrhunderten benutzen. Deine Aussage
Ach so - weil Du mich bisher nicht persönlich angegriffen hast findest Du, es wird jetzt langsam Zeit?
Wir hatten vorher auch schon Arbeit in den Text gesteckt...
beweist nochmals, dass Du es nicht erträgst wenn irgendetwas von Dir (wir schließt Dich ja mit ein) in Frage gestellt wird.
Das macht mich mit religiösen Eiferern gleich? Nun. Du versuchst an einer Aussage von mir festzumachen, dass ich generell keine Kritik ertrage, und jmd. der generell keine Kritik erträgt, der ist ja ein unsympathischer religiöser Eiferer, und der muss ja Unrecht haben! Oder wie soll daraus jetzt ein Argument werden. Selbst wenn ich generell mit Kritik ein Problem hätte würde das nicht beweisen, dass mein Zorn auch in diesem, einen Fall ungerechtfertigt ist. Du müsstest dennoch zeigen, dass ich in diesem einen Fall im Unrecht bin, weil das hier ja keine Diskussion über meine generellen, charakterlichen Defizite ist, sondern es geht ja um einen Wikiartikel. Ich finde aber nicht, dass es ein charakterliches Defizit von mir ist, wenn ich bedaure, dass eine Arbeit von mir im Orkus landet, ohne dass sich jemand die Mühe macht darzulegen, was daran schlecht ist. Es wird ja gerade nichts kritisiert, sondern nur die Arbeit von anderen, u.A. aber gar nicht in erster Linie von mir, abgewertet. Tatsächlich mag ich es nicht, wenn eine Leistung von mir auf solch ignorante Weise abgewertet wird. Das beweist aber natürlich nicht, dass ich generell ein Problem mit Kritik habe, und es beweist auch nicht, dass ich im vorliegenden Fall Unrecht habe. Es ist auch wieder nur ein rhetorischer Schachzug der mit der Dummheit der Leser spielt, die das nicht merken sollen. Und das macht mich wütend.
Zu meinem Vorschlag gab es eine Vorlage, die genau so vorging wie ich es umgesetzt habe. Diese Vorlage stammt aus Schulungsveranstaltungen zur Bash und hier bes. zu find. Da es aber nicht der Norm von user unknown entspricht verabschiede ich mich mit:
Jetzt sollen wir einer anonymen Vorlage die Referenz erweisen. Weder wird näher dargelegt, welche Autorität diese Vorlage legitimiert, noch werden wir in die Lage versetzt diese Vorlage selbst anzuschauen. Es ist komplett intransparent, worauf Du Dich beziehst, und ob Dir die Umsetzung der Vorlage gelungen ist; wir werden aufgefordert zu glauben dass Du erleuchtet bist, und die heilige Schrift persönlich empfangen hast. Aber ich bin religiös! Da fällt mir nichts mehr ein.
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29046
Wohnort: WW
|
Hallo, @user unknown: Bitte dem anderen gegenüber fair und respektvoll bleiben - auch wenn du sachlich Recht haben magst. Aber dem gegenüber der Diskussion mal ganz platt "Dummheit" und "Oberflächlichkeit" vorzuwerfen ist nicht ok. Weiterhin ist es so, dass ihr hier den Thread nicht nur mit gegenseitigen Anfeindungen, sondern auch mit einer Grundsatzdiskussion zu {} und deren Maskierung zu schmeißt. Letzteres mag auch am Ende auch für einen Artikel zu find von Bedeutung sein - so eine Diskussion gehört aber nicht hierhin, also wo es um den Artikel an sich geht. Zum Artikel: macht nur irgendwer irgendwas? Im Moment bin ich stark geneigt, die letzte Wiki-Revision wieder her zu stellen und wieder ins Wiki zu stellen. Gruß, noisefloor
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
Also ich finde auch den alten Artikel besser. Verständlicher geschrieben und man kommt schneller zu den Beispielen (bei der alten Version muss ich 3 Seiten runterscrollen, bei der neuen 6 Seiten). Die Beispiele selbst sind dann auch verständlicher, das erste Beispiel im neuen Artikel legt gleich los mit maxdepth und type, was man so normal erstmal ja nicht verwendet, das erste Beispiel im alten Artikel ist ein ganz herkömmliches find nach Dateiname. find ist aus meiner Sicht ein Befehl, der sehr einfach sein kann (zu find /verzeichnis -name muss man nicht viel erklären), aber auch sehr kompliziert werden kann (durch die Vielzahl der Kriterien). Anstatt den Leser erstmal mit ner langen Liste von Auswahlkriterien zu behelligen, würde ich erstmal mit dem einfachen find anfangen, sprich am Anfang des Artikels Beispiele zur einfachen Dateinamensuche bringen, und alles andere (maxdepth, type, !, schlagmichtot...) dann weiter unten in einem Abschnitt für Fortgeschrittene unterbringen. Idealerweise sollte man bei so einem Artikel auf der ersten Seite (also ohne zu scrollen) schon sehen können wie der Befehl funktioniert und die volle Breitseite erst bekommen wenn man weiter runter geht... so daß jemand der einfach nur eine Datei sucht (das wohl häufigste Anwendungsbeispiel für find) eben direkt an dem Beispiel oben sehen kann wie der Befehl aussehen muss, ohne groß auf der Artikelseite herumscrollen zu müssen. Ich werde mich aber hüten daran selbst herumzueditieren wenn hier schon wegen {} und anderem Krams so gestritten wird...
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
noisefloor schrieb: Hallo, @user unknown: Bitte dem anderen gegenüber fair und respektvoll bleiben - auch wenn du sachlich Recht haben magst. Aber dem gegenüber der Diskussion mal ganz platt "Dummheit" und "Oberflächlichkeit" vorzuwerfen ist nicht ok.
Wenn ich, entgegen meiner eigenen Behauptung und meinem ausdrücklichen Dementi wirklich Dummheit unterstellt hätte, dann bitte ich um einen Hinweis wo, damit ich die Stelle streichen/ändern kann. Ich halte RapaNui nicht für dumm. Obeflächlichkeit dagegen ist keine Herabsetzung. Wenn Du über den Kanal nach England schwimmen wolltest (gut, wer würde das wollen, schlechtes Wetter haben wir selbst genug, aber nur mal so) wäre es sinnvoll an der Oberfläche zu bleiben. Wenn Du nach einem Wrack tauchen willst natürlich weniger, aber in die Tiefe zu gehen ist nicht immer von Vorteil. Es ist eine Deutsche Oberflächlichkeit das Oberflächliche gering zu schätzen, und das Heil in der Tiefe zu vermuten, aber ich fürchte jetzt fühlst Du Dich auf den Schlips getreten, weil ich Dich in die Nähe von Oberflächlichkeiten gerückt habe. Ich habe ja, wenn ich mich recht erinnere, Oberflächlichkeit insofern diagnostiziert, als ich die Aussage der manpage dahingehend analysiert habe, dass es jenseits von Linux auf anderen unixoiden Systemen Shells geben könnte, oder gegeben haben könnte, die nicht POSIX-konform sind, und {} nicht an find weiterreichen, und daher eine Maskierung erfordern. Diese subtile Unterscheidung Linux-Unixoid war vorher nicht in der Diskussion, und deswegen beanspruche ich diese Tiefe entdeckt zu haben, und tiefer gegangen zu sein, als andere, die nicht analysiert haben, was der Satz genau bedeuten könnte, und welche Historie ihn geprägt hat, die es - so meine ich sagen zu dürfen - objektiv oberflächlicher betrachtet haben. Anregungen für bessere Adjektive nehme ich aber gerne auf. Was soll ich stattdessen sagen?
Zum Artikel: macht nur irgendwer irgendwas? Im Moment bin ich stark geneigt, die letzte Wiki-Revision wieder her zu stellen und wieder ins Wiki zu stellen.
Ich bitte darum, und biete an, meinen Vorschlag selbst umzusetzen, und zwar nach 2-3 kurzen Sätzen dazu, was find ist, mit einfachen Beispielen loszulegen, diese jeweils kurz zu erläutern, und dabei schrittweise neue oder mehr Optionen in Kombination zu zeigen, und die Optionslisten/-tabellen nach hinten zu rücken. Dabei würde ich gerne, soweit möglich, auf die Beispiele RapaNuis zurückgreifen - da waren ja durchaus gute Beispiele dabei. Das wäre aber nicht mehr möglich, wenn Du die alte Version rekonstruierst? Müßte man vorher eine Kopie dieses Abschnitts sich ziehen - das wäre ja auch kein Problem - ich mach das mal, falls es nötig sein sollte. Update: Wikisource habe ich mir lokal gespeichert.
|
noisefloor
Ehemaliger
(Themenstarter)
Anmeldungsdatum: 6. Juni 2006
Beiträge: 29046
Wohnort: WW
|
Hallo, @user unknown: Du kannst meinetwegen auch die aktuelle Baustelle nehmen und einen Re-Wrtie starten. Dann kannst du auch bestehende Textteile oder Beispiele per Copy&Paste übernehmen. Das mit dem Revision zurücksetzen und wieder ins Wiki muss nur sein, wenn niemand an dem Artikel arbeiten würde. Gruß, noisefloor
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Okay, ich lege mal los, und melde mich, um die kritik einzusammeln, spätestens in 24h mit einem Zwischenbericht.
|