make - Gnuwin32 find.exe expande el comodín antes de realizar la búsqueda

make 3.81 windows

Question

Estoy utilizando binarios Gnuwin32 en un entorno de Windows.
Cuando quiero encontrar archivos de cierto tipo, digamos PDF, normalmente ejecuto:

find . -iname ''*.pdf'' -print

Esto funciona perfectamente en cualquier sistema UNIX.

find.exe . -iname "*.pdf" -print

Pero bajo Windows, al haber reemplazado las comillas simples por comillas dobles, solo funciona cuando no hay un archivo pdf en el directorio actual, de lo contrario, el * se expande .

Peor aún: cuando exista exactamente un archivo PDF en el directorio actual, se expandirá, no habrá ningún error de sintaxis y obtendrá resultados incorrectos.

He intentado escapar del * con un cursor, una barra invertida, una estrella, poniendo comillas dobles: nada funciona para mí.

Ejemplo real:

Bien, aquí están todos mis archivos:

C:/tmp>find . -type f
./a/1.pdf
./a/2.pdf
./a/aa/1.pdf
./b/1.pdf
./b/bb/1.pdf
./b/bb/2.pdf

Buen comportamiento, el comodín no fue ampliado.

C:/tmp>find . -iname "*.pdf"
./a/1.pdf
./a/2.pdf
./a/aa/1.pdf
./b/1.pdf
./b/bb/1.pdf
./b/bb/2.pdf

C:/tmp>cd a

Precaución, comportamiento inconsistente, comodín fue ampliado:

C:/tmp/a>find . -iname "*.pdf"
find: paths must precede expression
Usage: find [-H] [-L] [-P] [path...] [expression]

C:tmp/a>cd ../b

Precaución, comportamiento inconsistente, comodín fue ampliado:

C:/tmp/b>find . -iname "*.pdf"
./1.pdf
./bb/1.pdf

Gracias

Answer 1

@OP, tengo un comportamiento consistente

C:/test/temp>find . -iname "*.txt"
./1.txt
./2.txt

C:/test/temp>cd a

C:/test/temp/a>find . -iname "*.txt"

C:/test/temp/a>cd ../b

C:/test/temp/b>find . -iname "*.txt"

C:/test/temp/b>find --version
GNU find version 4.2.20
Features enabled: CACHE_IDS D_TYPE

Puede intentar utilizar findutils lugar de UnxUtils.

Answer 2

Me he encontrado la solución a mi problema.

• Find.exe de find.exe no funciona en las versiones recientes de Windows (Vista, Seven) porque expande los comodines que coinciden solo con el contenido del directorio actual.
• Del mismo modo, una versión anterior de find.exe de UnxUtils sufrió el mismo error.
• El último find.exe de UnxUtils está funcionando.

Answer 3

No he encontrado nada mejor que simplemente evitar los caracteres comodín

find.exe . -iregex ".+/.pdf" -print

Answer 4

Sufrí este problema esta tarde. Los UnxUtils de Benoit pueden funcionar. También encuentro que find.exe de MinGW puede funcionar, está bajo mi

"MinGW / msys / 1.0 / bin"

directorio. Y es consistente con el manual.

gnuwin32 y UnxUtils: find.exe . -name GameCli* find.exe . -name GameCli* trabajo, pero find.exe . -name ''GameCli*'' find.exe . -name ''GameCli*'' no funciona.

find.exe . -name ''GameCli*'' de MinGW find.exe . -name ''GameCli*'' find.exe . -name ''GameCli*'' trabajo.

Answer 5

Una solución es agregar un comodín / expansión que el shell de Windows no expande, pero la búsqueda de GNU sí:

find.exe . -name *[.:]pdf -print

El shell de Windows [*] no interpreta / amplía las llaves cuadradas. Además, los dos puntos no son un carácter válido en los nombres de archivo de Windows, por lo que este patrón no puede coincidir con ningún nombre de archivo de Windows, y el shell de Windows siempre pasará el patrón a través de find.exe.

Luego, Find.exe encontrará los archivos que terminen en .pdf o :pdf , pero como ningún archivo puede tener un nombre que termine en :pdf en Windows, solo encontrará los archivos que terminen en .pdf .

[*] En realidad, es el tiempo de ejecución de C el que no realiza estas expansiones de comodín. No entiendo el tiempo de ejecución de Win32 C lo suficiente como para refinar la distinción, por lo que, por ahora, con el propósito de esta solución, solo digo "shell".