¿Cómo puedo excluir todos los mensajes de "permiso denegado" de "buscar"?

Question

necesito ocultar todo Permiso denegado mensajes de:

find . > files_and_folders

Estoy experimentando cuando surge ese mensaje.Necesito reunir todas las carpetas y archivos a los que no surge.

¿Es posible dirigir los niveles de permiso al files_and_folders ¿archivo?

¿Cómo puedo ocultar los errores al mismo tiempo?

Answer 1

<sup>Nota:
* Esta respuesta probablemente va más allá de lo que garantiza el caso de uso, y find 2>/dev/null puede ser lo suficientemente bueno en muchas situaciones.Todavía puede ser de interés por una perspectiva multiplataforma y por su discusión de algunas técnicas avanzadas de shell con el fin de encontrar una solución que sea lo más sólida posible, aunque los casos contra los que se protege pueden ser en gran medida hipotéticos.
* Si su sistema está configurado para mostrar localizado error de mensajes, anteponga el find llamadas a continuación con LC_ALL=C (LC_ALL=C find ...) para asegurar eso Inglés Los mensajes se informan, de modo que grep -v 'Permission denied' funciona según lo previsto.Sin embargo, invariablemente, cualquier mensaje de error que hacer que se muestre también estará en inglés.</sup>

Si tu el caparazón es bash o zsh, hay una solución que es robusta y al mismo tiempo razonablemente simple, usando sólo compatible con POSIX find características;mientras bash en sí no es parte de POSIX, la mayoría de las plataformas Unix modernas lo incluyen, lo que hace que esta solución sea ampliamente portátil:

find . > files_and_folders 2> >(grep -v 'Permission denied' >&2)

Nota:Existe una pequeña posibilidad de que algunos de grepLa salida puede llegar después find se completa, porque el comando general no espera el comando interno >(...) para terminar.En bash, puedes evitar esto agregando | cat al comando.

• >(...) es un (rara vez usado) producción sustitución de procesos que permite redirigir la salida (en este caso, stderr producción (2>) a la entrada estándar del comando dentro >(...).
  Además de bash y zsh, ksh también los apoya en principio, pero intentando combinarlos con la redirección desde stderr, como se hace aquí (2> >(...)), parece ser silenciosamente ignorado (en ksh 93u+).

  • grep -v 'Permission denied' filtros afuera (-v) todas las líneas (desde el find flujo stderr del comando) que contienen la frase Permission denied y envía las líneas restantes a stderr (>&2).

Este enfoque es:

• robusto: grep sólo se aplica a error de mensajes (y no a una combinación de rutas de archivo y mensajes de error, lo que podría generar falsos positivos), y los mensajes de error distintos de los de permiso denegado se pasan a stderr.

• libre de efectos secundarios: findEl código de salida de se conserva:la imposibilidad de acceder al menos a uno de los elementos del sistema de archivos encontrados genera un código de salida 1 (aunque eso no le dirá si hay errores otro que los de permiso denegado (también)).

---

Soluciones compatibles con POSIX:

Las soluciones totalmente compatibles con POSIX tienen limitaciones o requieren trabajo adicional.

Si findLa salida de debe ser capturada en un archivo de todos modos (o suprimida por completo), entonces la solución basada en tuberías de La respuesta de Jonathan Leffler es simple, robusto y compatible con POSIX:

find . 2>&1 >files_and_folders | grep -v 'Permission denied' >&2

Tenga en cuenta que el orden de las redirecciones es importante: 2>&1 debes venir primero.

Capturar la salida estándar en un archivo por adelantado permite 2>&1 mandar solo mensajes de error a través de la canalización, que grep entonces puede operar sin ambigüedades.

El el único inconveniente es que el código de salida general será el grep comando, no find's, que en este caso significa:Si hay No errores en absoluto o solo errores de permiso denegado, el código de salida será 1 (señalización falla), en caso contrario (errores distintos de los de permiso denegado) 0 - que es lo contrario de la intención.
Dicho eso, findDe todos modos, el código de salida rara vez se usa, ya que a menudo transmite poca información más allá fundamental fracaso como pasar por un camino inexistente.
Sin embargo, el caso específico de incluso sólo alguno de que las rutas de entrada sean inaccesibles debido a la falta de permisos es reflejado en findEl código de salida (tanto en GNU como en BSD). find):si se produce un error de permisos denegados para cualquier de los archivos procesados, el código de salida se establece en 1.

La siguiente variación aborda eso:

find . 2>&1 >files_and_folders | { grep -v 'Permission denied' >&2; [ $? -eq 1 ]; }

Ahora, el código de salida indica si hay algún error. otro que Permission denied ocurrió: 1 en ese caso, 0 de lo contrario.
En otras palabras:el código de salida ahora refleja la verdadera intención del comando:éxito (0) se informa, si no hay ningún error o solo Se produjeron errores de permiso denegado.
Podría decirse que esto es incluso mejor que simplemente pasar findel código de salida, como en la solución en la parte superior.

---

gniourf_gniourf en los comentarios propone un (aún compatible con POSIX) Generalización de esta solución mediante redirecciones sofisticadas., cual funciona incluso con el comportamiento predeterminado de imprimir las rutas de los archivos a salida estándar:

{ find . 3>&2 2>&1 1>&3 | grep -v 'Permission denied' >&3; } 3>&2 2>&1

En breve:Descriptor de archivo personalizado 3 se utiliza para intercambiar temporalmente stdout (1) y estándar (2), para que los mensajes de error solo se puede canalizar a grep a través de salida estándar.

Sin estas redirecciones, ambos datos (rutas de archivos) y los mensajes de error se enviarían a grep a través de salida estándar, y grep Entonces no sería capaz de distinguir entre mensaje de error Permission denied y un (hipotético) archivo cuyo nombre contiene la frase Permission denied.

Sin embargo, como en la primera solución, el código de salida informado será grepes, no find's, pero se puede aplicar la misma solución anterior.

---

Notas sobre las respuestas existentes:

• Hay varios puntos a tener en cuenta sobre La respuesta de Michael Brux, find . ! -readable -prune -o -print:

  • Requiere ÑU find;en particular, no funcionará en macOS.Por supuesto, si sólo necesitas el comando para trabajar con GNU find, esto no será un problema para ti.

  • Alguno Permission denied los errores pueden aún superficie: find ! -readable -prune informa tales errores para el niño elementos de directorios para los cuales el usuario actual tiene r permiso, pero carece x permiso (ejecutable).La razón es que debido a que el directorio en sí es legible, -prune no se ejecuta, y el intento de descender en ese directorio luego activa los mensajes de error.Dicho esto, el típico el caso es para el r permiso para faltar.

  • Nota:El siguiente punto es una cuestión de filosofía y/o caso de uso específico, y usted puede decidir que no es relevante para usted y que el comando se adapta bien a sus necesidades, especialmente si simplemente impresión los caminos es todo lo que haces:

    • Si conceptualizas el filtrado de los mensajes de error de permiso denegado separado tarea a la que desea poder postularse cualquier find comando, entonces el enfoque opuesto de proactivamente previniendo Los errores de permiso denegado requieren introducir "ruido" en el find comando, que también introduce complejidad y lógica trampas.
    • Por ejemplo, el comentario más votado sobre la respuesta de Michael (al momento de escribir este artículo) intenta mostrar cómo extender el comando incluyendo un -name filtrar, de la siguiente manera:
      find . ! -readable -prune -o -name '*.txt'
      Esto, sin embargo, no no funciona según lo previsto, porque el final -print la acción es requerido (puede encontrar una explicación en esta respuesta).Estas sutilezas pueden introducir errores.

• La primera solución en La respuesta de Jonathan Leffler, find . 2>/dev/null > files_and_folders, como él mismo afirma, Silencia ciegamente todo error de mensajes (y la solución es engorrosa y no completamente sólida, como también explica). Pragmáticamente hablando, sin embargo, es el solución más simple, ya que puede contentarse con asumir que todos y cada uno de los errores estarían relacionados con los permisos.

• la respuesta de la niebla, sudo find . > files_and_folders, es conciso y pragmático, pero desaconsejado para cualquier otra cosa que no sea simplemente impresión nombres de archivos, por razones de seguridad:porque estás corriendo como el raíz usuario, "corres el riesgo de que todo tu sistema se arruine por un error en find o una versión maliciosa, o una invocación incorrecta que escribe algo inesperado, lo que no podría suceder si ejecutaras esto con privilegios normales" (de un comentario en la respuesta de Mist por triple).

• La segunda solución en la respuesta del viraptor, find . 2>&1 | grep -v 'Permission denied' > some_file corre el riesgo de obtener falsos positivos (debido al envío de una combinación de stdout y stderr a través del proceso) y, potencialmente, en lugar de informar no-Errores de permiso denegado a través de stderr, los captura junto con las rutas de salida en el archivo de salida.

Answer 2

Uso:

find . 2>/dev/null > files_and_folders

Esto oculta no sólo los errores Permission denied, por supuesto, pero todos los mensajes de error.

Si realmente quiere mantener otros posibles errores, como demasiados saltos en un enlace simbólico, pero no las ha denegado el permiso, entonces usted probablemente tiene que tomar un vuelo adivinar que usted no tiene muchos archivos denominados ' permiso denegado' y tratar:

find . 2>&1 | grep -v 'Permission denied' > files_and_folders

---

Si desea filtrar estrictamente error simplemente estándar, puede utilizar la construcción más elaborada:

find . 2>&1 > files_and_folders | grep -v 'Permission denied' >&2

La redirección de E / S en el comando find es: 2>&1 > files_and_folders |. El tubo redirige la salida estándar al comando grep y se aplicó por primera vez. El 2>&1 envía el error estándar para el mismo lugar que la salida estándar (la tubería). El > files_and_folders envía la salida estándar (pero no el error estándar) en un archivo. El resultado neto es que los mensajes escritos en el error estándar son enviados por el tubo y la salida regular de find se escriben en el archivo. El grep filtra la salida estándar (que puede decidir cómo selectiva se quiere que sea, y puede que tenga que cambiar la ortografía según la zona y O / S) y la >&2 último significa que los mensajes de error que sobreviven (escritos en la salida estándar) van al error estándar una vez más. La redirección final podría ser considerada como opcional en la terminal, pero sería una muy buena idea para usarlo en una secuencia de comandos para que los mensajes de error en error estándar.

Hay un sinfín de variaciones sobre este tema, dependiendo de lo que quiere hacer. Esto funcionará en cualquier variante de Unix con cualquier Bourne shell derivado (Bash, Korn, ...) y cualquier versión compatible con POSIX de find .

Si desea adaptarse a la versión específica de find que tiene en su sistema, puede haber opciones alternativas disponibles. find GNU en particular, tiene una miríada de opciones no disponibles en otras versiones -. Véase la respuesta actualmente aceptado para un tal conjunto de opciones

Answer 3

Uso:

find . ! -readable -prune -o -print

o más generalmente

find <paths> ! -readable -prune -o <other conditions like -name> -print

• para evitar el "Permiso denegado"
• Y no suprimir los mensajes (otra) de error
• y obtener el código de salida 0 ( "todos los archivos se procesan correctamente")

Funciona con: Buscar (findutils) 4.4.2. Antecedentes:

• La prueba -readable coincide con archivos legibles. El operador ! devuelve verdadero, cuando la prueba es falsa. Y ! -readable coincide directorios no legibles (y archivos).
• La acción -prune no entra en el directorio.
• ! -readable -prune puede ser traducido a: si el directorio no se puede leer, no descienden en ella
.
• La prueba -readable tiene en cuenta las listas de control de acceso y otros artefactos de permisos que ignora la prueba -perm.

find (1) página de manual para muchos más detalles.

Answer 4

Si desea iniciar la búsqueda de la raíz "/", es probable que vea tantos de salida como:

find: /./proc/1731/fdinfo: Permission denied
find: /./proc/2032/task/2032/fd: Permission denied

Es debido permiso. Para solucionar esto:

1. Puede utilizar el comando sudo: sudo find /. -name 'toBeSearched.file'. pide la contraseña de super usuario, cuando se introduzca la contraseña verá como resultado lo que realmente quiere.

2. Puede utilizar redirigir la salida de error estándar a partir de (Generalmente Display / Pantalla) para algún archivo y no ver los mensajes de error en la pantalla! redirigir a un archivo / dev / null especial:

   find /. -name 'toBeSearched.file' 2>/dev/null
   

3. Puede utilizar redirigir la salida de error estándar a partir de (Generalmente Display / Pantalla) a la salida estándar (generalmente muestran / pantalla), entonces la tubería con el comando grep -v con el parámetro "invertido" para no ver las líneas de salida que tiene 'permiso denegado' pares de palabras:

   find /. -name 'toBeSearched.file' 2>&1 | grep -v 'Permission denied'
   

Answer 5

he tenido que usar:

find / -name expect 2>/dev/null

especifica el nombre de lo que quería encontrar y luego diciéndole que se redirigir todos los errores a / dev / null

esperar ser la ubicación del programa esperan que estaba buscando.

Answer 6

stderr Pipe a /dev/null utilizando 2> / dev / null

find . -name '...' 2>/dev/null

Answer 7

También puede utilizar el -perm y -prune predicados para evitar descender en directorios ilegibles (véase también ¿Cómo se quita "permiso denegado" declaraciones impresión del programa de descubrimiento - Unix y Linux Pila Cambio ):?

find . -type d ! -perm -g+r,u+r,o+r -prune -o -print > files_and_folders

Answer 8

Redirigir error estándar. Por ejemplo, si está utilizando bash en una máquina Unix, puede redirigir el error estándar a / dev / null como esto:

find . 2>/dev/null >files_and_folders

Answer 9

Si bien los métodos anteriores no resuelven el caso de Mac OS X porque Mac OS X no es compatible con el interruptor -readable esto es cómo se puede evitar 'Permiso denegado' errores en su salida. Esto podría ayudar a alguien.

find / -type f -name "your_pattern" 2>/dev/null.

Si está utilizando algún otro comando con find, por ejemplo, para encontrar el tamaño de los archivos de cierto patrón en un directorio 2>/dev/null todavía funcionaría como se muestra a continuación.

find . -type f -name "your_pattern" -exec du -ch {} + 2>/dev/null | grep total$.

Esto devolverá el tamaño total de los archivos de un patrón dado. Tenga en cuenta el 2>/dev/null al final del comando find.

Answer 10

Esos errores se imprimen a la salida de error estándar (fd 2). Filtrarlos, simplemente redirigir todos los errores a / dev / null:

find . 2>/dev/null > some_file

o el primer unirse a stderr y stdout y luego grep a cabo esos errores específicos:

find . 2>&1 | grep -v 'Permission denied' > some_file

Answer 11

Respuesta simple:

find . > files_and_folders 2>&-

2>&- cierra (-) la norma descriptor de archivo de error (2) para que todos los mensajes de error son silenciados.

código
• Salir todavía será 1 si de otro modo se imprimirían los errores de cualquier 'Permission denied'

respuesta robusta para find GNU:

find . -type d \! \( -readable -executable \) -prune -print -o -print > files_and_folders

Pasar opciones adicionales para que find -prune (evitar descender a) pero todavía -print cualquier directorio ( -type d) que no lo hace ( \! ) tienen tanto -readable y -executable por misiones, o ( -o ) -print cualquier otro archivo.

• -readable y opciones -executable son extensiones de GNU, no parte de la estándar POSIX
• Todavía puede volver 'Permission denied sobre los archivos corruptos / anormales (por ejemplo, véase informe de error afectan a los sistemas de ficheros montados sobre el recipiente utilizando lxcfs

respuesta robusta que funciona con cualquier find compatible con POSIX (GNU, OSX / BSD, etc)

{ LC_ALL=C find . 3>&2 2>&1 1>&3 > files_and_folders | grep -v 'Permission denied'; [ $? = 1 ]; } 3>&2 2>&1

Utilizar un tubería para pasar la norma flujo de error a grep , la eliminación de todas las líneas que contienen la cadena 'Permission denied'.

LC_ALL=C establece el href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_02" rel="noreferrer"> POSIX local utilizando una ambiente variables, 3>&2 2>&1 1>&3 y 3>&2 2>&1 descriptores de archivos duplicados para canalizar el flujo de error estándar para grep y usos [ $? = 1 ] [] para invertir el código de error devuelto por grep para aproximar el comportamiento original de find.

• también filtrará cualquier error 'Permission denied' debido a la redirección de la salida (por ejemplo, si el archivo se files_and_foldersyo no es modificable)

Answer 12

Para evitar solo el permiso denegado advertencias, informe a encontrar a ignorar los archivos ilegibles por la poda de la búsqueda. Añadir una expresión como un OR a su hallazgo, como

find / \! -readable -prune -o -name '*.jbd' -ls

Esto dice en su mayoría a (que coincida con un archivo ilegible y podarlo de la lista) o (que coincida con un nombre como * .jbd y mostrarlo [con ls]) . (Recuerde que por defecto las expresiones están relacionados por AND juntos a menos que utilice -o.) Necesita los -ls en la segunda expresión o de lo contrario puede encontrar agregar una acción predeterminada para mostrar ya sea partido, que también le mostrará todos los archivos ilegibles .

Pero si usted está en busca de archivos reales en el sistema, por lo general hay ninguna razón para buscar en / dev, que tiene muchos muchos archivos, por lo que hay que añadir una expresión que excluye ese directorio, como:

find / -mount \! -readable -prune  -o  -path /dev -prune  -o  -name '*.jbd' -ls

Entonces (archivo ilegible partido y podar de la lista) o (partido de ruta / dev y podar de la lista) o (archivo partido como * .jbd y mostrarlo) .

Answer 13

uso

sudo find / -name file.txt

Es estúpido (porque usted eleva la búsqueda) y no seguro, pero mucho más corto para escribir.

Answer 14

Ninguna de las respuestas anteriores trabajado para mí. Lo que encuentro en Internet se centra en: ocultar errores. Ninguno maneja adecuadamente el / salida de código de proceso de retorno de código. Yo uso hallazgo mando dentro de scripts bash para localizar algunos directorios y luego inspeccionar su contenido. Evalúo comando de encontrar el éxito mediante la salida de código: un valor cero obras, de lo contrario no

.

El respuesta proporcionada anteriormente por Michael Brux funciona a veces. Pero tengo un escenario en el que se produce un error! He descubierto el problema y lo arreglé yo mismo. Necesito podar archivos cuando:

it is a directory AND has no read access AND/OR has no execute access

Vea la cuestión clave aquí es: Y / O. Una buena condición secuencia sugerida leí es:

-type d ! -readable ! -executable -prune

Esto no funciona siempre. Esto significa una ciruela pasa se desencadena cuando un partido es:

it is directory AND no read access AND no execute access

Esta secuencia de expresiones falla cuando se concede acceso de lectura, pero el acceso no es ejecutar.

Después de algunas pruebas me di cuenta de eso y me cambió la solución a script de shell:

  

agradable hallazgo / home * / -maxdepth 5-Siga \
  \ (-Type d -a ! \ (-Readable -a -executable \) \) -prune \
  -o \
  \ (-Type d -a -readable -a -executable -a -name "$ {} m_find_name" \) -print

La clave aquí es colocar el "no es cierto" para una expresión combinada:

has read access AND has execute access

De lo contrario, no tiene acceso completo, lo que significa: podarlo. Esto resultó trabajar para mí en un escenario en el que las soluciones sugeridas anteriores fracasaron.

proporciono a continuación detalles técnicos para las preguntas en la sección de comentarios. Me disculpo si los detalles son excesivas.

• ¿Por qué el uso de comando nice? Tengo la idea aquí . Al principio pensé que sería bueno para reducir la prioridad del proceso cuando se busca un sistema de ficheros entero. Me di cuenta de que no tiene sentido para mí, ya que mi escritura se limita a unos cuantos directorios. Reduje -maxdepth a 3.
• ¿Por qué buscar dentro de / home * /? Esto no resulta relevante a este hilo. Instalar todas las aplicaciones a mano a través de compilar el código fuente con los no usuarios privilegiados (no root). Se instalan dentro de "/ home". Puedo tener múltiples versiones binarios y viven juntos. Necesito localizar a todos los directorios, inspeccionar y copia de seguridad de un modo maestro-esclavo. Puedo tener más de un "/ home" (varios discos que se ejecutan en un servidor dedicado).
• ¿Por qué el uso de -seguir? Los usuarios pueden crear enlaces simbólicos a directorios. Es utilidad depende, tengo que llevar un registro de las rutas absolutas encontrados.

Answer 15

Puede utilizar el grep -v invertido-partido

-v, --invert-match        select non-matching lines

como esto:

find . > files_and_folders
cat files_and_folders | grep -v "permission denied" > files_and_folders

En caso de que la magia

Answer 16

- = Para MacOS = -

Hacer un nuevo comando usando alias: sólo tiene que añadir en ~ / .bash_profile línea:

alias search='find / -name $file 2>/dev/null'

y en una nueva ventana de terminal se puede llamar así:

$ file=<filename or mask>; search

  

por ejemplo:

     

$ archivo = etc; buscar

Answer 17

Si está utilizando csh, aquí es una solución:

( find . > files_and_folders ) >& /dev/null

Si desea una salida al terminal:

( find . > /dev/tty ) >& /dev/null

Sin embargo, como el FAQ "CSH-whynot" describe, no se debe utilizar CSH.

Answer 18

También una solución fácil de poner sus resultados encontrar en un archivo.

encontrar. -name 'NameOfSearchedFile' >> results.txt