GNU encuentra y enmascara el {} para algunos shells, ¿cuál?

La página del manual para GNU find states:

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

Eso es del hombre a find(GNU findutils) 4.4.2.

Ahora probé esto con bash y dash, y no es necesario que ambos {}estén enmascarados. Aquí hay una prueba simple:

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

¿Hay un caparazón, para el cual realmente necesito enmascarar los frenos? Tenga en cuenta que no depende de si el archivo encontrado contiene un espacio en blanco (invocado desde bash):

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

Esto cambia si el archivo encontrado se pasa a una subshell:

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

que puede resolverse mediante:

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

en contraste con:

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

pero eso no es de lo que habla la página man, ¿verdad? Entonces, ¿qué shell trata {}de una manera diferente?

Resumen : si alguna vez hubo un shell que se expandió {}, es un legado realmente antiguo por ahora.

En el shell Bourne y en los shells compatibles con POSIX, los corchetes ( {y }) son caracteres ordinarios (a diferencia de (y )que son delimitadores de palabras como ;y &, y [y ]que son caracteres globales). Se supone que las siguientes cadenas deben imprimirse literalmente:

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

Una palabra que consiste en una sola llave es una palabra reservada , que solo es especial si es la primera palabra de un comando.

Ksh implementa la expansión de llaves como una extensión incompatible al shell Bourne. Esto se puede desactivar con set +B. Bash emula ksh a este respecto. Zsh también implementa la expansión de llaves; allí se puede apagar con set +Io setopt ignore_braceso emulate sh. Ninguno de estos shells se expande {}en ningún caso, incluso cuando es una subcadena de una palabra (p foo{}bar. Ej. ), Debido al uso común en argumentos para findy xargs.

Single Unix v2 señala que

En algunos sistemas históricos, las llaves se tratan como operadores de control. Para ayudar en futuras actividades de estandarización, las aplicaciones portátiles deben evitar el uso de llaves sin comillas para representar los propios caracteres. Es posible que una versión futura del estándar ISO / IEC 9945-2: 1993 lo requiera {y }sea ​​tratado individualmente como operadores de control, aunque el token {}probablemente será una excepción de caso especial debido a la find {}construcción de uso frecuente .

Esta nota se eliminó en versiones posteriores del estándar; los ejemplos parafind tienen usos sin comillas de {}, al igual que los ejemplos paraxargs . Puede haber habido conchas históricas de Bourne donde {}debían citarse, pero ahora serían sistemas heredados realmente antiguos.

Las implementaciones de CSH que tengo a la mano (OpenBSD 4.7, CSH BSD en Debian , tcsh) todo se expanden {foo}a foopero dejan {}solo.

El {}necesitaba ser citado en versiones de la fishcáscara antes de 3.0.0.

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

Y en el shell rc (también akangabasado en rc, pero no es):

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

Es probable que esos no sean los shells que los autores de esa documentación de GNU tenían en mente cuando escribieron ese texto desde que fishse lanzó por primera vez en 2005 (mientras que ese texto o similar ya estaba allí en 1994) y rcoriginalmente no era un shell de Unix.

Hay algunos rumores de que algunas versiones de csh(el shell que introdujo la expansión de llaves) lo requieren. Pero es difícil darles crédito a ellos ya que el primer lanzamiento de csh2BSD no lo hizo. Aquí, como se probó en un emulador PDP11:

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

Y la página del manual de 2BSD cshdice claramente :

Como caso especial, `{',`}' y `{} 'se pasan sin molestias.

Por lo tanto, me resultaría muy extraño si una versión posterior de csh o tcsh lo rompiera más tarde.

Podría haber sido evitar algunos errores en algunas versiones. Aún con ese 2BSD csh (eso es lo mismo en 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

Sin embargo, las citas no ayudan:

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

Podría citar toda la sustitución del comando:

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

Pero eso es pasar un argumento a ese eco externo.

En csho tcsh, debe citar el {}cuando no está solo, como en:

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

(aunque ese tipo de finduso no es portátil ya que algunos finds solo se expanden {}por sí solos).

En una palabra, csh. bashy otros shells modernos reconocen que el usuario probablemente no está solicitando una expansión de llaves nulas. (Modern cshes en realidad tcshy ahora también puede manejarlo {}sensualmente)