find (1): ¿cómo se implementa el comodín estrella para que falle en algunos nombres de archivo?

En un sistema de archivos donde los nombres de archivo están en UTF-8, tengo un archivo con un nombre defectuoso; se muestra como:, D�sinstallernombre real de acuerdo con zsh:, D$'\351'sinstallerLatin1 para Désinstallersí mismo, una barbarie francesa para "desinstalar". Zsh no coincidiría con él, [[ $file =~ '^.*$' ]]pero lo haría con un problema: este *es el comportamiento que espero.

Ahora todavía espero encontrarlo cuando lo find . -name '*'ejecuto; de hecho, nunca esperaría que un nombre de archivo falle esta prueba. Sin embargo, con LANG=en_US.utf8, el archivo no aparece, y tengo que configurarlo LANG=C(o en_US, o '') para que funcione.

Pregunta: ¿Cuál es la implementación detrás y cómo podría haber predicho ese resultado?

_{Información: Arch Linux 3.14.37-1-lts, find (GNU findutils) 4.4.2}

Esa es una muy buena captura. De un vistazo rápido al código fuente de GNU find, diría que esto se reduce a cómo se fnmatchcomporta en secuencias de bytes no válidas ( pred_name_commonen pred.c):

b = fnmatch (str, base, flags) == 0;
(...)
return b;

Este código prueba el valor de retorno de fnmatchigualdad con 0, pero no verifica los errores; esto da como resultado que cualquier error sea reportado como "no coincide".

Se sugirió, hace muchos años, cambiar el comportamiento de esta función libc para que siempre devuelva verdadero en el *patrón, incluso en nombres de archivos rotos, pero por lo que puedo decir, la idea debe haber sido rechazada (vea el hilo que comienza en https : //sourceware.org/ml/libc-hacker/2002-11/msg00071.html ):

Cuando fnmatch detecta un carácter multibyte no válido, debe recurrir a la coincidencia de un solo byte, de modo que "*" tenga la posibilidad de hacer coincidir dicha cadena.

¿Y por qué es esto mejor o más correcto? ¿Existe alguna práctica existente?

Según lo mencionado por Stéphane Chazelas en un comentario, y también en el mismo hilo de 2002, esto es inconsistente con la expansión glob realizada por los proyectiles, que no ahogan los caracteres no válidos. Quizás aún más desconcertante es el hecho de que revertir la prueba solo coincidirá con aquellos archivos que tienen nombres rotos (cree archivos en bash con touch $'D\351marrer' $'Touch\303\251' $'\346\227\245\346\234\254\350\252\236'):

$ find -name '*'
.
./Touché
./日本語

$ find -not -name '*'
./D?marrer

Entonces, para responder a su pregunta, podría haber predicho esto al conocer el comportamiento de su fnmatchen este caso y al saber cómo findmaneja el valor de retorno de esta función; probablemente no podría haberlo descubierto únicamente leyendo la documentación.

La -name opción de búsqueda utiliza la notación de coincidencia de patrón de shell para realizar la coincidencia del nombre de archivo. *es un patrón que coincide con varios caracteres , debe coincidir con una cadena de cero o más caracteres.

findusa fnmatch para verificar la coincidencia de patrones, por lo que puede usar ltrace para verificar el resultado:

$ touch $'\U1212'aa
$ touch D$'\351'sinstaller
$ LC_ALL=en_US.utf8 ltrace -e fnmatch find -name '*'          
find->fnmatch("foo", "foo", 0)                   = 0
find->fnmatch("Foo", "foo", 0)                   = 1
find->fnmatch("Foo", "foo", 16)                  = 0
find->fnmatch("*", ".", 0)                       = 0
.
find->fnmatch("*", "D\351sinstaller", 0)         = -1
find->fnmatch("*", "\341\210\222aa", 0)          = 0
./ሒaa
+++ exited (status 0) +++

Con D\351sinstaller, fnmatchreturn -1, indicó que no pudo coincidir. Se ሒaaemparejará un carácter válido como .

En su caso, con la UTF-8configuración regional, \351es un carácter no válido, lo que hace que falle la coincidencia de patrones.