¿Por qué encontrar a veces coincide con su argumento de ruta de línea de comando?

En Linux,

cd /tmp
mkdir foo; cd foo

Ahora corriendo

find . -name 'foo'

no da salida Mientras que correr

find /tmp/foo -name 'foo'

Da el resultado /tmp/fooque no tiene sentido para mí. ¿Alguien puede explicar por qué?

findatraviesa los árboles de directorios especificados y evalúa la expresión dada para cada archivo que encuentra. El recorrido comienza en el camino dado. Aquí hay un resumen de cómo find . -name foofunciona:

• Primera ruta en la línea de comando: .
  • ¿El nombre base ( .) coincide con el patrón foo? No, entonces no hagas nada.
    Sucede que /tmp/fooes otro nombre para el mismo directorio. Pero findno lo sabe (y se supone que no debe intentar averiguarlo).
  • ¿Es la ruta un directorio? Sí, entonces atravesarlo. Enumere las entradas .y, para cada entrada, realice el proceso transversal.
    • El directorio está vacío: no contiene ninguna entrada que no sea .y .., que findno recorre recursivamente. Entonces el trabajo está terminado.

Y find /tmp/foo:

• Primera ruta en la línea de comando: /tmp/foo
  • ¿El nombre base ( foo) coincide con el patrón foo? Sí, entonces la condición coincide.
    • No hay ninguna acción asociada con esta condición, por lo tanto, realice la acción predeterminada, que es imprimir la ruta.
  • ¿Es la ruta un directorio? Sí, entonces atravesarlo. Enumere las entradas /tmp/fooy, para cada entrada, realice el proceso transversal.
    • El directorio está vacío: no contiene ninguna entrada que no sea .y .., que findno recorre recursivamente. Entonces el trabajo está terminado.

Se da la circunstancia de que .y /tmp/fooson el mismo directorio, pero eso no es suficiente para garantizar que findtiene el mismo comportamiento en ambos. El findcomando tiene formas de distinguir entre rutas al mismo archivo; El -namepredicado es uno de ellos. find /tmp/foo -name foocoincide con el directorio de inicio, así como con cualquier archivo debajo que se llame foo. find . -name .solo coincide con el directorio inicial ( .nunca se puede encontrar durante un recorrido recursivo).

No hay normalización de los argumentos de la línea de comando antes de que se apliquen las pruebas. Por lo tanto, los resultados difieren dependiendo de la ruta utilizada (si están involucrados enlaces simbólicos):

cd /tmp
mkdir foo
ln -s foo bar
find /tmp/foo -name foo
find /tmp/bar -name foo

En "su caso" ambas llamadas darían el mismo resultado que podría ser (más) confuso. Puede usarlo -mindepth 1si desea que se ignoren los puntos de partida (puede que no sean POSIX).

(gnu) find muestra las coincidencias encontradas dentro de la ruta proporcionada al comando porque comienza su comparación con los argumentos de la línea de comandos, descendiendo más profundamente en la estructura del directorio desde allí (por lo tanto, -maxdepth 0limita las pruebas al nivel base o solo a los argumentos de la línea de comandos, mientras que -mindepth 1omite los argumentos de la línea de comandos como se man findexplica Esta es la razón por la find /tmp/foo -name 'foo'cual producirá una coincidencia incluso si el directorio en sí está vacío.

find . -name 'foo'por otro lado, no dará ningún resultado porque .(punto) es un archivo especial que actúa como un enlace rígido al mismo inodo que /tmp/foo: es como un nombre de archivo separado (aunque especial) y no un enlace simbólico o una expresión sujeta a expansión del nombre de ruta por el shell. Por lo tanto, la primera prueba aplicada por find a los argumentos de la línea de comandos en el ejemplo dado no mostrará coincidencias, ya que de .hecho no coincide con el patrón de nombre definido en -name 'foo'. Tampoco lo hace, /tmp/foo/.ya que una prueba para un -namepatrón se realiza solo en el nombre base de la ruta (ver man find), que aquí está nuevamente ..

Si bien este comportamiento puede no esperarse o parecer intuitivo desde la perspectiva del usuario (y sí, al principio también me confundió), no constituye un error, sino que corresponde con la lógica y la funcionalidad descritas en las páginas de manual e información para ( ñu) encontrar.

Intenté comentar la respuesta de Gilles, pero fue demasiado largo para caber en un comentario. Por esta razón, lo pongo como respuesta a mi propia pregunta.

La explicación de Gilles (y la de Shevek también) es clara y tiene sentido. El punto clave aquí es que no solo findintenta hacer coincidir los nombres de archivo para los archivos dentro de las rutas dadas (recursivamente), sino que también trata de hacer coincidir el nombre base de las rutas dadas.

Por otro lado, ¿hay alguna prueba de que esta es la forma en que findse supone que funciona, en lugar de ser un error? En mi opinión, sería mejor si no hace que los resultados sean inconsistentes find .y find ABSOLUTE-PATHporque la inconsistencia siempre es confusa y podría desperdiciar mucho tiempo al desarrollador tratando de descubrir "qué estaba mal". En mi caso, estaba escribiendo un guión, y la ruta se tomó de una variable. Entonces, para que mi script funcione correctamente, lo que puedo pensar es escribir find $path/. -name 'pattern'.

Finalmente, creo que se pueden obtener resultados consistentes findal sustituir siempre .el directorio actual por el directorio actual antes de continuar.

No hay ningún objeto nombrado fooen el directorio donde inició la búsqueda relativa.

Está en lo cierto al suponer que gfindtiene errores cuando informa /tmp/foocuando se usa el nombre absoluto como directorio de inicio.

Gfindtiene varias desviaciones del estándar, parece que encontraste otra. Cuando desee una solución compatible más estándar, le recomiendo sfindque sea parte del schilytools.

-namese aplica a los resultados de búsqueda del directorio. Ninguno de los dos casos que menciona devolverá una entrada de directorio foode una readdir()operación.