GNU trouve et masque les {} pour quelques obus - lequel?

La page de manuel de GNU Find indique les états suivants:

-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. 

Cela va de l'homme à find(GNU findutils) 4.4.2.

Maintenant, j'ai testé cela avec bash et dash, et les deux n'ont pas besoin d' {}être masqués. Voici un test simple:

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

Y at-il une coquille, pour laquelle j'ai vraiment besoin de masquer les accolades? Notez que cela ne dépend pas de savoir si le fichier trouvé contient un blanc (appelé depuis bash):

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

Cela change si le fichier trouvé est passé dans un sous-shell:

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

qui peut être résolu par:

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

contrairement à:

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

mais ce n'est pas ce dont parle la page de manuel, n'est-ce pas? Alors, quelle coquille traite {}d'une manière différente?

Résumé : Si jamais un shell s’agrandissait {}, c’est maintenant du passé .

Dans le shell Bourne et dans les shell compatibles POSIX, les accolades ( {et }) sont des caractères ordinaires (contrairement à (et )qui sont des délimiteurs de mots comme ;et &, et [et ]qui sont des caractères globaux). Les chaînes suivantes sont toutes supposées être imprimées littéralement:

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

Un mot constitué d'une seule accolade est un mot réservé , qui n'est spécial que s'il s'agit du premier mot d'une commande.

Ksh implémente le développement d'accolade en tant qu'extension incompatible du shell Bourne. Cela peut être désactivé avec set +B. Bash émule ksh à cet égard. Zsh implémente également l'expansion des corsets; il peut être désactivé avec set +Iou setopt ignore_bracesou emulate sh. {}En aucun cas, aucun de ces shells ne se développe , même s'il s'agit d'une sous-chaîne d'un mot (par exemple foo{}bar), en raison de l'utilisation courante dans les arguments de findet xargs.

Single Unix v2 note que

Dans certains systèmes historiques, les accolades sont traitées comme des opérateurs de contrôle. Pour faciliter les futures activités de normalisation, les applications portables devraient éviter d’utiliser des accolades sans guillemets pour représenter les caractères eux-mêmes. Il est possible qu'une future version de la norme ISO / IEC 9945-2: 1993 exige {et }soit traitée individuellement en tant qu'opérateurs de contrôle, bien que le jeton {}constitue probablement une exception spéciale dans ce cas en raison de la find {}structure souvent utilisée .

Cette note a été supprimée dans les versions suivantes de la norme. les exemples pourfind des utilisations non citées de {}, de même que les exemples pourxargs . Il y a peut-être eu des coquilles Bourne historiques où il a {}fallu citer, mais il s'agirait vraiment de vieux systèmes hérités.

Les implémentations csh que j'ai sous la main (OpenBSD 4.7, BSD csh sur Debian , tcsh) se développent toutes {foo}en foolaissant de côté {}.

Le {}besoin d'être cité dans les versions du fishshell avant la version 3.0.0.

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

Et dans le shell rc (également akangabasé sur rc, mais pas es):

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

Ce ne sont probablement pas les réservoirs que les auteurs de la documentation de découverte GNU avaient en tête lorsqu'ils ont écrit ce texte depuis fishsa première publication en 2005 (alors que ce texte ou similaire existait déjà en 1994) et qu'il rcne s'agissait pas à l'origine d'un shell Unix.

Certaines rumeurs disent que certaines versions de csh(le shell qui a introduit le développement par accolade) en ont besoin. Mais il est difficile d’en attribuer le mérite à ceux qui se sont produits depuis la première version de csh2BSD. Ici comme testé dans un émulateur PDP11:

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

Et la page de manuel de 2BSD cshindique clairement :

Dans des cas spéciaux, "{", "}" et "{}" sont passés sans être dérangés.

Donc, je trouverais cela très étrange si une version ultérieure de csh ou de tcsh le cassait plus tard.

Cela aurait pu être de contourner certains bugs dans certaines versions. Toujours avec ce csh 2BSD (c'est la même chose dans 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

Citant n'aide pas si:

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

Vous pouvez citer toute la substitution de commande:

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

Mais cela passe un argument à cet écho extérieur.

En cshou tcsh, vous auriez besoin de citer le {}quand pas seul comme dans:

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

(Bien que ce type d’ findutilisation ne soit pas portable car certains findne s’agrandissent {}que par eux-mêmes).

En un mot, csh. bashet d'autres coques modernes reconnaissent que l'utilisateur ne demande probablement pas une extension null Brace. (Moderne cshest en fait tcshet peut également traiter de manière {}saine maintenant.)