staging.inyokaproject.org

Hallo,

Baustelle/Shell/find

Gruß
noisefloor

Habe einige Syntaxfehler korrigiert. Vielleicht sollte man das Argument für -name in allen Beispielen in Anführungszeichen bringen. Es schadet nämlich nicht, wenn sie in Verbindung mit Platzhaltern fehlen aber schon.

Hallo,

verschoben: Shell/find

Gruß
noisefloor

Ich hab die Ausgabeumleitung in eine Datei von "-printf Datei" in "> Datei" geändert, da mit der alten Variante je Treffer Datei auf der Standardausgabe ausgegeben wurde und nicht wie gewollt die Treffer in die Datei Datei geschrieben wurden.

Gruß Thomas

Aber > Datei ist keine Aktion des find-Kommandos, sondern eine simple Ausgabe-Umleitung der Shell. Richtig muss es heißen:

-fprint Datei

Korrigiert.

Hallo,

gut Danke. ☺

Die Version von arima teppei ist "richtiger", weil das fprint eben zu find gehört. Auch wenn die Umleitung mit > sicherlich auch funktioniert, ist das andere im Kontext des Artikels besser.

Gruß, noisefloor

(Ich hoffe ich interpretiere das richtig, daß man bei Wikiartikeln auch alte Threads aus der Versenkung holt - sie sind ja dauerhaft verlinkt.)

2 Ärgernisse: Das kleine vom Ende des Artikels zuerst:

find /home/user -type f -name "*.txt" -exec grep Ubuntu "{}" \; 

Die geschweiften Klammern {} sollten mit "" maskiert werden, um Dateinamen mit Leerzeichen u.dgl. korrekt zu verarbeiten.

Das stimmt nicht. Find ruft grep auch in Dateinamen mit Blank ohne Anführungsstriche korrekt auf - find weiß was der Dateiname ist, und ruft die Programme selbst korrekt auf. Man möge ein Gegenbeispiel präsentieren wenn man kann. Bis dahin habe ich den Artikel korrigiert:

find /home/user -type f -name "*.txt" -exec grep Ubuntu {} \; 

So mein neuer Text darunter:

Die geschweiften Klammern {} brauchen nicht mit "" maskiert zu werden, da find die Programme - hier grep - selbst richtig aufruft. Das, was dem -exec und seinen Partnern folgt, ist nicht Shellcode, und so werden auch viele Sachen, die in der Shell funtkionieren nicht klappen.

Schlimmer ist der Beginn des Artikels:

Benutzung¶

Die allgemeine Syntax von find lautet:

find Suchpfad -Suchkriterium <Aktion(en)> 

Der Suchpfad und das Suchkriterium sind dabei Pflichtangaben, eine Aktion (bzw. Aktionen) sind optional.

Das widerspricht der Hilfe, dem empirischen Befund, leitet in die Irre, und teils ins Verderben.

Die manpage sagt:

SYNOPSIS
       find [-H] [-L] [-P] [-D debugopts] [-Olevel] [path...] [expression]

Eckige Klammern sagen, daß diese Teile optional sind - also außer dem Wort find alles.
Probiert es bitte aus.

Eine Unterscheidung Suchkriterium/Aktion gibt es in der Art nicht, und v.a. keine vorgeschriebene Reihenfolge, und wie man hier http://forum.ubuntuusers.de/post/2395741/ sieht können die Folgen verheerend sein.

Ich weiß auch nicht, wieso man im Wiki sich einer eigenen Syntax mit <spitzen Klammern> befleißigt - will man die User oder die Wikischreiber überlasten - wieso verwendet man nicht die man-Schreibweise mit eckigen Klammern? Dann hätten beide Seiten die Möglichkeit diese Syntax zu lernen, und zu lernen, daß es etwas bedeutet, und verläßlich ist, und nicht so nach Gefühl - hier machen wir mal Klammern hin, ist vielleicht optional.

Meine Korrektur sieht so aus:

Benutzung¶

Die allgemeine Syntax von find lautet:

find <Suchpfad> <-optionen>

Optionen können Filter sein wie Dateityp, Größe, Alter; mittels -exec Programme, die true/false zurückgeben, und es können Aktionen für die gefundenen Dateien angestoßen werden. Die Reihenfolge ist signifikant.

Hallo,

kannst du beides gerne korrigeren. ☺

wieso man im Wiki sich einer eigenen Syntax mit <spitzen Klammern> befleißigt

Die Aussage stimmt so in der Form nicht. Dazu gab es vor 2 oder 3 Jahren (?) schon mal eine Diskussion, u.a. mit dir (?).

Jedenfalls gibt eine keine verbindliche Regelung (ja, das gibt es auch im Wiki von ubuntuusers!), wie sowas dargestellt wird. Irgendwie sollte man optionale Parameter kennzeichnen - nur leider hat in der Shell ja fast alles ( <> [] {} ) eine Bedeutung... Gängig und IMHO auch sinnvoll ist seit eingier Zeit, alles GROSS zu schreiben, also

find SUCHPFAD -OPTIONEN

Das ist "relativ" eindeutig.

Kannst du das auch hier übernehmen? ☺

Gruß, noisefloor

In der Shell haben die Zeichen eine Bedeutung, ja. Ich meine damals hieß es, es gäbe ein Buch, welches < und > verwendet. Es könnte auch vom Kontext abhängen, was gut und was weniger gut ist. In

find SUCHPFAD -OPTIONEN

würde ich SUCHPFAD und OPTIONEN erstmal als etwas auffassen, was mit eigenen Werten gefüllt werden muß, während find so stehen bleiben muß.

find SUCHPFAD -delete

-delete dagegen ist ein Schlüsselwort, welches genau so geschrieben werden muß.

Ich bin aber zuwenig mit dem Wiki beschäftigt um einen Überblick zu haben, und will nicht, nur weil hier und da die Schreibweise mit eckigen Klammern üblich ist, diese durchsetzen mit meinem kl. Horizont.

Ärgerlicher ist ja, dass da eine Aussage stand, die nicht stimmte. Dann regt man sich gerne über andere Dinge auf, die einem sonst so ins Auge fallen, und über die man sich überhaupt gerne aufregt. "Schlag Deinen Bruder nicht, und räum mal das Zimmer auf, und zum Friseur könntest Du auch mal wieder" - so in der Art.

Hallo,

find SUCHPFAD -OPTIONEN

würde ich SUCHPFAD und OPTIONEN erstmal als etwas auffassen, was mit eigenen Werten gefüllt werden muß, während find so stehen bleiben muß.

find SUCHPFAD -delete

Sehe ich auch so. Kannst du IMHO so machen.

Gruß, noisefloor

Ich würde gerne diesen Artikel generalüberholen.

• beinhaltet kleinere Fehler

• ist nicht Anfängerfreundlich

Meine Idee ist etwas aufwendiger um es im orig. Artikel zu ändern, bitte in die Baustelle

RapaNui

P.S. Es ist zwar fast 1 Jahr her und nicht falsch, dennoch möchte ich gerne Antworten.

user unknown schrieb:

Die geschweiften Klammern {} sollten mit "" maskiert werden, ...

Das stimmt nicht. Find ruft grep auch in Dateinamen mit Blank ohne Anführungsstriche korrekt auf - find weiß was der Dateiname ist, und ruft die Programme selbst korrekt auf. Man möge ein Gegenbeispiel präsentieren wenn man kann.

Das stimmt in soweit, dass find die Dateienamen korrekt an grep weitergibt, aber

So mein neuer Text darunter:

Die geschweiften Klammern {} brauchen nicht mit "" maskiert zu werden, da find die Programme - hier grep - selbst richtig aufruft. Das, was dem -exec und seinen Partnern folgt, ist nicht Shellcode, und so werden auch viele Sachen, die in der Shell funtkionieren nicht klappen.

das stimmt so nicht. Wird find im Terminal ausgeführt (bash oder dash, andere kenn ich nicht), dann wird eine "brace expansion" versucht durchzuführen, mit dem Ergebnis "nichts zu expandieren", da Angaben fehlen. Sollten aber Werte mitgegeben werden (was hier unsinnig wäre, da von find eindeutig als {} gefordert), so erfolgt diese Expansion. Mit '{}' bemühe ich also erst gar nicht die bash/dash zwecks Interpretationsversuch.

Beispiele:

find . -maxdepth 1 -type f -name ".bashrc" -exec grep "^#" {} \;

mit Ergebnis:

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
# ~/.bash_logout: executed by bash(1) when login shell exits.
 ..........

und jetzt den Unsinn:

find . -maxdepth 1 -type f -name ".bashrc"  -exec grep "^#" foo{1,2} \;

mit Ergebnis:

grep: foo1: Datei oder Verzeichnis nicht gefunden
grep: foo2: Datei oder Verzeichnis nicht gefunden

Also könnte man schon sagen: Der Platzhalter für die ermittelten Dateien/Verzeichnisse {} sollte vor der Shell versteckt werden, z.B. so: '{}'.

Saludos

Wieso schneidest Du auch beim Zitieren ab, was ursprünglich dort stand:

Die geschweiften Klammern {} sollten mit "" maskiert werden, um Dateinamen mit Leerzeichen u.dgl. korrekt zu verarbeiten.

Nur die Zeichenfolge

1

{}

hat eine bestimmte Bedeutung für find, die man in der manpage nachschlagen kann. Von

1

{1,2}

ist da nirgends die Rede. Wenn Du also {1,2} maskieren willst bist Du herzlich dazu eingeladen - es hat halt nichts mit find zu tun.

1
2
3
4
5
6
7
8
9

ibmux:~/tmp > find -name "*.sh" -exec echo {1,2}{} \; 
1./praes.sh 2./praes.sh
1./adhoc.sh 2./adhoc.sh
ibmux:~/tmp > find -name "*.sh" -exec echo {1,2}'{}' \; 
1./praes.sh 2./praes.sh
1./adhoc.sh 2./adhoc.sh
ibmux:~/tmp > find -name "*.sh" -exec echo '{1,2}'{} \; 
{1,2}./praes.sh
{1,2}./adhoc.sh

Du müßtest entweder zeigen, daß es einen Unterschied macht, ob ich das {} maskiere oder nicht, oder dass es einen Rechner gibt, auf dem man die Zeit die man beim maskieren verliert wieder hereinholt, weil die Shell da irgendwas nicht mehr zu interpretieren versucht.

Oder worauf möchtest Du hinaus?

Hola, user unknown schrieb:

Wieso schneidest Du auch beim Zitieren ab, was ursprünglich dort stand:

Zuerst entschuldige ich mich dafür, dass ich falsch abgeschnitten habe. Das find auch ohne die Maskierung von {} korrekt arbeitet hab ich ja bestätigt. Auch das mein 2. Beispiel Unsinn ist habe ich mMn deutlich gemacht.

Hintergrund ist, in den Manpag zu find wird eben auch der Hinweis gegeben:

The string `{}' is replaced by the current file name being processed everywhere it occurs in the arguments to the command, 
not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped 
(with a `\') or quoted to protect them from expansion by the shell.

und selbst in der dt. Manpage steht

 die Klammern und das Semikolon müssen in der Kommandozeile für find quotiert werden, damit sie nicht von der Shell bearbeitet werden.

Da ich mich an einer Überarbeitung des Artikels versuche habe ich dies eben auch aufgenommen, allerdings ohne den idiotischen Bezug zu Leerzeichen und Sonderzeichen.

Mein Aufhänger war mehr die Aussage:

was dem -exec und seinen Partnern folgt, ist nicht Shellcode, und so werden auch viele Sachen, die in der Shell funtkionieren nicht klappen.

Der 2. Teilsatz trifft voll zu, es klappt nicht. Die Aussage zum Shellcode finde ich zweideutig, Du hast Recht und die Manpageauthoren haben auch Recht. Der Shell ist es egal ob die Anweisung für das Programm find gedacht ist, wenn in ihr Kommandos ausgeführt werden und sie die Anweisungen kennt (hier: brace expansion), dann versucht sie auch eine Interpretation.

Aber lassen wir das, es ist eigentlich (hier in diesem Fall) nur Haarspalterei.

Oder worauf möchtest Du hinaus?

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:

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. Ich pers. finde das Konstrukt: find Anweisungen -exec Befehl '{}' \; gut, es grenzt optisch von den anderen Optionen und Anweisunge ab.

Wenn der Artikel dann mal in der Baustelle ist, würde ich mich freuen, wenn Du ihn unter die Lupe nehmen würdest - ich hoffe ich hab da nicht zu viel Mist gebaut.

Saludos, RapaNui

P.S. Bitte find in die Baustelle verschieben, Danke.

RapaNui schrieb:

Das find auch ohne die Maskierung von {} korrekt arbeitet hab ich ja bestätigt. Auch das mein 2. Beispiel Unsinn ist habe ich mMn deutlich gemacht.

Ja, wieso bringst Du denn Beispiele die Du selbst unsinnig findest?

Hintergrund ist, in den Manpag zu find wird eben auch der Hinweis gegeben:

The string `{}' is replaced by the current file name being processed everywhere it occurs in the arguments to the command, 
not just in arguments where it is alone, as in some versions of find. Both of these constructions might need to be escaped 
(with a `\') or quoted to protect them from expansion by the shell.

und selbst in der dt. Manpage steht

 die Klammern und das Semikolon müssen in der Kommandozeile für find quotiert werden, damit sie nicht von der Shell bearbeitet werden.

Das steht da, aber was bedeutet es? Dass die Shell die {} frisst bevor find sie verarbeitet, oder wenn find die Ergebnisse mit -exec ... {} verarbeitet? Vielleicht

1

-exec bash -c "..." {} \;

? Vielleicht gibt es Konflikte mit einer anderen Shell?

Mit der bash, vorher jedenfalls nicht. Und die dt. Übersetzung ist bei allem was ich von Englisch weiß falsch, denn 'might need' heißt m.W. 'könnte ... benötigen' und nicht 'müssen'.

Der 2. Teilsatz trifft voll zu, es klappt nicht. Die Aussage zum Shellcode finde ich zweideutig, Du hast Recht und die Manpageauthoren haben auch Recht. Der Shell ist es egal ob die Anweisung für das Programm find gedacht ist, wenn in ihr Kommandos ausgeführt werden und sie die Anweisungen kennt (hier: brace expansion), dann versucht sie auch eine Interpretation.

Welche Shell hast Du denn geprüft?

Aber lassen wir das, es ist eigentlich (hier in diesem Fall) nur Haarspalterei.

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.

Oder worauf möchtest Du hinaus?

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:

Hinweis:

Der Platzhalter "{}" sollte und das Semikolon ";" muss quotiert/maskiert werden, damit die Shell^[4] diese Anweisungen an find übergibt und nicht selber interpretiert, z.B. so: '{}' \; Dabei ist zu beachten, dass zwischen dem {} und dem ; ein Leerzeichen gesetzt wird. Details und Einschränkungen zu allen vorhandenen Optionen findet man in der Manpage^[2] sowie den Infoseiten zu find.

'might need to be' heißt nicht 'sollte', sondern 'es könnte nötig sein', soweit mein Englisch reicht.

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.

Ich pers. finde das Konstrukt: find Anweisungen -exec Befehl '{}' \; gut, es grenzt optisch von den anderen Optionen und Anweisunge ab.

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.

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.

Wenn der Artikel dann mal in der Baustelle ist, würde ich mich freuen, wenn Du ihn unter die Lupe nehmen würdest - ich hoffe ich hab da nicht zu viel Mist gebaut.

Die Lupe geht bei mir irgendwie automatisch an, wenn ich ins Wiki schaue - ich weiß auch nicht wieso. ☺

Hallo,

bitte schön: Baustelle/find

Gruß, noisefloor