Respuestas:
El &de 2>&1simplemente dice que el número 1es un descriptor de archivo y no un nombre de archivo. En este caso el standard output file descriptor.
Si lo usa 2>1, esto redirigiría los errores a un archivo llamado, 1pero si lo usa 2>&1, lo enviaría al standard output stream.
Esto &>dice enviar ambos standard outputy standard error, en alguna parte. Por ejemplo, ls <non-existent_file> &> out.file. Permítanme ilustrar esto con un ejemplo.
Preparar:
Cree un archivo kokocon el siguiente contenido:
#!bin/bash
ls j1
echo "koko2"
Hazlo ejecutable: chmod u+x koko
Ahora tenga en cuenta que j1no existe
Ahora corre ./koko &> output
corre cat outputy verás
ls: cannot access 'j1': No such file or directory
koko2
Ambos, standard error( ls: cannot access 'j1': No such file or directory) y standard output( koko2), fueron enviados al archivo output.
Ahora ejecútelo nuevamente, pero esta vez así:
./koko > output
Hazlo cat outputy solo verás lo koko2mismo. Pero no el resultado de error del ls j1comando. Eso será enviado a standard errorlo que verá en su terminal.
Nota importante gracias a @Byte Commander:
Tenga en cuenta que en command >file 2>&1el orden de la redirección es importante. Si escribe en su command 2>&1 >filelugar (que normalmente no es lo que desea), primero redirigirá los comandos stdoutal archivo y luego redirigirá los comandos stderra su estado no utilizado stdout, por lo que aparecerá en el terminal y podrá canalizarlo o redirigirlo nuevamente, pero no se escribirá en el archivo.
command >file 2>&1el orden de las redirecciones es importante. Si escribe en su command 2>&1 >filelugar (que normalmente no es lo que desea), primero redirigirá el stdout del comando al archivo y luego redirigirá el stderr del comando a su stdout ahora no utilizado, por lo que aparecerá en la terminal y podrá canalizarlo o redirigirlo nuevamente, pero no se escribirá en el archivo.
standard outputlo que verá en su terminal". ¿No debería ser esto "para el standard error"?
> FILE 2>&1y &> FILEson equivalentes Ver 8.2.3.2. Redirección de errores en la Guía Bash para Principiantes Capítulo 8
&> FILEsolo es específico de Bash, mientras que >FILE 2>&1se entiende por un mayor número de shells
Se [n]>&worddenomina Descriptor de archivos de salida duplicados (consulte la sección 2.7.6 del estándar POSIX Shell Language). Este comportamiento particular es característica de Bourne-como conchas, entre ellos ksh, dashy bash; de hecho, el estándar se basa en Bourne shell y ksh. Al examinar los manuales de tcsh y csh , aparentemente no ofrecen la capacidad de duplicar ningún descriptor de archivo, sin embargo, a partir de la descripción de >&, esto se comporta como &>en bash(es decir, redirige los errores y la salida normal al archivo).
En los sistemas similares a * nix, incluido Ubuntu, a menudo escuchas que todo es un archivo, o más bien un descriptor de archivo . La salida estándar es el descriptor de archivo constante 1 y el error estándar es el descriptor de archivo 2. Entonces, > FILE 2>&1técnicamente significa duplicar el descriptor de archivo 2 en el descriptor de archivo 1. En otras palabras de esta respuesta :
El 2> & 1 le dice al shell que le dé al comando un descriptor de archivo 2 que sea un duplicado del descriptor 1. (es decir, stderr y stdout apuntan al mismo fd).
La clave aquí es tener en cuenta que el descriptor 1 debe configurarse primero. Debido a que el shell procesa las redirecciones en orden de izquierda a derecha, command >FILE 2>&1le dice al shell que vuelva a cablear stdout para commandentrar FILEprimero, y solo entonces el descriptor 2 puede convertirse en una copia de 1, es decir, 1 y 2 apuntan a la misma ubicación FILE.
Por supuesto, esto va más allá del error estándar y la salida estándar. Como se muestra en esta respuesta , haciendo3&>2
... duplicas (dup2) filedescritor 2 en filedescriptor 3, posiblemente cerrando filedescriptor 3 si ya está abierto
Un ejemplo de manipulación de descriptores de archivos, entre muchos, sería capturar la salida del dialogcomando en una variable
También vale la pena señalar que &>es específico para bash. En zshesto se comporta igual, pero según la documentación, "... no tiene el mismo efecto que '> palabra 2> & 1' en presencia de multios". En POSIX compatible /bin/sh, esto se trataría como una redirección regular con poner el comando en segundo plano. Vea también, ¿Hay algún código sh que no sea un código bash sintácticamente válido? .
Ver también:
&>significa