GNU findet und maskiert die {} für einige Shells - welche?

Die Manpage für GNU find lautet:

-exec command ;
    [...] 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. 

Das ist vom Mann bis find(GNU findutils) 4.4.2.

Jetzt habe ich dies mit Bash und Dash getestet, und beide müssen nicht {}maskiert sein. Hier ist ein einfacher Test:

find /etc -name "hosts" -exec md5sum {} \; 

Gibt es eine Muschel, für die ich die Zahnspangen wirklich maskieren muss? Beachten Sie, dass es nicht davon abhängt, ob die gefundene Datei ein Leerzeichen enthält (wird von bash aufgerufen):

find ~ -maxdepth 1 -type d -name "U*" -exec ls -d {} \; 
/home/stefan/Ubuntu One

Dies ändert sich, wenn die gefundene Datei an eine Subshell übergeben wird:

find ~ -maxdepth 3 -type d -name "U*" -exec bash -c 'ls -d {}' \; 
ls: cannot access /home/stefan/Ubuntu: No such file or directory
ls: cannot access One: No such file or directory

was gelöst werden kann durch:

find ~ -maxdepth 3 -type d -name "U*" -exec bash -c 'ls -d "$0"' {} \;

im Kontrast zu:

find ~ -maxdepth 3 -type d -name "U*" -exec bash -c 'ls -d "{}"' \; 
/home/stefan/Ubuntu One

Aber darum geht es doch nicht in der Manpage, oder? Also, welche Muschel behandelt {}auf eine andere Art und Weise?

Fazit : Wenn es jemals eine Shell gab, die erweitert wurde {}, ist sie mittlerweile wirklich alt.

In dem Bourne - Shell und in POSIX-compliant shells, Zahnspange ( {und }) sind gewöhnliche Zeichen ( im Gegensatz zu, (und )die Worttrennzeichen sind wie ;und &und [und ]die Globbing Zeichen). Die folgenden Zeichenfolgen sollen alle wörtlich gedruckt werden:

$ echo { } {} {foo,bar} {1..3}
{ } {} {foo,bar} {1..3}

Ein Wort, das aus einer einzelnen geschweiften Klammer besteht, ist ein reserviertes Wort . Dies ist nur dann etwas Besonderes, wenn es das erste Wort eines Befehls ist.

Ksh implementiert die Klammererweiterung als inkompatible Erweiterung der Bourne-Shell. Dies kann mit ausgeschaltet werden set +B. Bash emuliert in dieser Hinsicht ksh. Zsh implementiert auch die Klammererweiterung. dort kann es mit set +Ioder setopt ignore_bracesoder ausgeschaltet werden emulate sh. Keine dieser Shells wird {}auf jeden Fall erweitert, auch wenn es sich um eine Teilzeichenfolge eines Wortes handelt (z. B. foo{}bar), da sie häufig in Argumenten für findund verwendet wird xargs.

Single Unix v2 merkt das an

In einigen historischen Systemen werden die geschweiften Klammern als Steueroperatoren behandelt. Um zukünftige Standardisierungsaktivitäten zu unterstützen, sollten tragbare Anwendungen die Verwendung nicht zitierter Klammern zur Darstellung der Zeichen selbst vermeiden. Es ist möglich, dass eine zukünftige Version der Norm ISO / IEC 9945-2: 1993 dies erfordert {und }einzeln als Steueroperatoren behandelt wird, obwohl das Token {}aufgrund des häufig verwendeten find {}Konstrukts wahrscheinlich eine Sonderfallausnahme davon sein wird .

Diese Notiz wurde in nachfolgenden Versionen des Standards entfernt. Die Beispiele fürfind haben nicht zitierte Verwendungen von {}, wie auch die Beispiele fürxargs . Es mag historische Bourne-Muscheln gegeben haben, in denen {}zitiert werden musste, aber sie wären inzwischen wirklich alte Legacy-Systeme.

Die csh-Implementierungen, die ich zur Hand habe (OpenBSD 4.7, BSD csh unter Debian , tcsh), erweitern sich alle, lassen {foo}sich fooaber in {}Ruhe.

Das {}musste in Versionen der fishShell vor 3.0.0 zitiert werden .

$ fish -c 'echo find -exec {} \;'
find -exec  ;

Und in der RC-Shell (auch akangabasierend auf rc, aber nicht es):

$ rc -c "echo find -exec {} ';'"
line 1: syntax error near '{'

Das sind wahrscheinlich nicht die Shells, an die die Autoren dieser GNU-Funddokumentation gedacht hatten, als sie diesen Text geschrieben haben, seit er fish2005 zum ersten Mal veröffentlicht wurde (während dieser Text oder ähnliches bereits 1994 da war) und rcursprünglich keine Unix-Shell waren.

Es gibt einige Gerüchte, dass einige Versionen csh(der Shell, die die Klammererweiterung eingeführt hat) dies erfordern. Aber es ist schwer, diese zu würdigen, seitdem die erste Veröffentlichung von cshin 2BSD dies nicht getan hat. Hier, wie in einem PDP11-Emulator getestet:

# echo find -exec {} \;
find -exec {} ;

Und in der Manpage von 2BSD heißt es csheindeutig :

Als Sonderfall werden `{',`}' und `{} 'ungestört übergeben.

Ich würde es sehr seltsam finden, wenn eine nachfolgende Version von csh oder tcsh das später kaputt machen würde.

Es hätte sein können, dass in einigen Versionen einige Fehler behoben wurden. Immer noch mit dieser 2BSD csh (das ist dasselbe in 2.79BSD, 2.8BSD, 2.11BSD):

# csh -x
# echo foo {} bar
echo foo {} bar
foo {} bar
# echo `echo foo {} bar`
echo `echo foo {} bar`
echo foo {} bar
foo  bar

Das Zitieren hilft jedoch nicht:

# echo `echo foo '{}' bar`
echo `echo foo '{}' bar`
echo foo {} bar
foo  bar

Sie könnten die gesamte Befehlsersetzung zitieren:

# echo "`echo foo {} bar`"
echo `echo foo {} bar`
echo foo {} bar
foo {} bar

Aber das ist ein Argument für dieses äußere Echo.

In cshoder tcshmüsstest du das zitieren, {}wenn es nicht alleine ist wie in:

find . -name '*.txt' -type f -exec cp {} '{}.back' \;

(obwohl diese Art der findNutzung nicht portabel ist, da einige finds nur erweitert werden, {}wenn sie für sich alleine sind).

Mit einem Wort csh. bashund andere moderne Shells erkennen, dass der Benutzer wahrscheinlich nicht nach einer Null-Klammer-Erweiterung fragt. (Modern cshist eigentlich tcshund kann {}mittlerweile auch vernünftig umgehen .)