¿Cuáles son las diferencias entre &> y 2> & 1

Hay dos formas de redireccionar la salida estándar y el error estándar en la salida estándar . ¿Pero cual es mejor? y por qué &>se considera el perfecto?

No puedo encontrar cuáles son las diferencias, por lo que muchos tutoriales e incluso bash manual indican que &>es mejor.

Entonces, ¿por qué debo usar &>y no2>&1

Principalmente usando bashshell

EDITAR: gracias por los comentaristas

Solo> y funciona en csh o tcsh

En ksh solo funcionan 2> & 1.

dash use> file 2> & 1 solo redirección

¡Entonces cuál usar para asegurar que mi script sea compatible con otros sistemas, sean cuales sean los shells usados!

La página de manual de Bash menciona que hay dos formas de redirigir stderr y stdout : &> file y >& file. Ahora, observe que dice tanto stderr como stdout.

En este caso >file 2>&1, estamos redirigiendo stdout (1) al archivo, ¡pero también le estamos diciendo a stderr (2) que se redirija al mismo lugar que stdout! Entonces, el propósito puede ser el mismo, pero la idea es ligeramente diferente. En otras palabras "John, ve a la escuela; Suzzie ve a donde va John".

¿Qué pasa con la preferencia? &>es una bashcosa Entonces, si está portando un script, eso no lo hará. Pero si está 100% seguro de que su script solo funcionará en el sistema con bash, entonces no hay preferencia

Aquí hay un ejemplo con dashDebian Amquist Shell, que es el predeterminado de Ubuntu.

$ grep "YOLO" * &> /dev/null
$ grep: Desktop: Is a directory
grep: Documents: Is a directory
grep: Downloads: Is a directory
grep: Music: Is a directory
grep: Pictures: Is a directory
grep: Public: Is a directory
grep: Templates: Is a directory
grep: Videos: Is a directory
grep: YOLO: Is a directory
grep: bin: Is a directory

Como puede ver, stderr no se redirige

Para abordar sus ediciones en la pregunta, puede usar la instrucción if para verificar la variable $ SHELL y cambiar las redirecciones en consecuencia

Pero para la mayoría de los casos > file 2>&1debería funcionar

En términos más técnicos, el formulario [integer]>&wordse denomina Descriptor de archivos de salida duplicados y es una característica especificada por el estándar POSIX Shell Command Language, que es compatible con la mayoría de los shells compatibles con POSIX y similares a Brourne.

Consulte también ¿Qué significa y significa exactamente en la redirección de salida?

En general, recomendaría seguir la forma de hacer las cosas de Bourne-SHell , ya que bash es posiblemente el shell de Unix más popular que existe. Bash generalmente usa &>o 2>&1. En mi humilde opinión, ninguno de los dos es "perfecto", así que recomiendo olvidarse de esas tonterías. Siendo realistas, cuál debe usar depende de lo que esté tratando de hacer.

2>&1combina stderr con stdout, lo que puede ser útil si, por ejemplo, desea canalizar texto stderr. Entonces, por ejemplo, si desea ver si un programa imprime un determinado mensaje stderr, pero no desea que su pantalla se llene de basura (presumiblemente) sin importancia, puede hacer algo como program 2>&1 | grep crashed, que buscará stdout y stderr desde un programa llamado "programa" para la palabra "bloqueado".

Por otro lado, si no desea que un programa imprima nada, simplemente puede ejecutar program &> /dev/null, lo que redirigirá tanto stderr como stdout a / dev / null, un archivo especial que mágicamente hace que las cosas desaparezcan. O, si desea guardar la salida de un programa (tal vez para informar un error o algo), puede redirigir tanto stderr como stdout a un archivo: program &> log.txtredirigirá todos los datos a un archivo llamado "log.txt". Si lo desea, puede redirigir stdout y stderr a través de program 2> log.txt > log.txto program 2>&1 | cat > log.txt, los cuales tendrían el mismo efecto que usar &>. Si hace algo así program 2>&1 > file, solo se redireccionará stdout, pero stderr aún se puede canalizar a otro programa, como cat, que podría redirigirse como se muestra arriba. Sin embargo, escribiendo&>es más fácil que cualquiera de los ejemplos anteriores, ya que implica escribir menos caracteres (y es un poco más fácil de leer para los seres humanos). Tenga en cuenta que program 2> log.txt > log.txtpodría ser más probable que funcione en shells que no sean bash.

PD: si te preocupa que las personas usen otros shells, hay algo que puedes agregar a la primera línea de tu script llamado "número mágico" o "shebang". Esta es esencialmente una forma de asegurarse de que otras computadoras (particularmente aquellas que ejecutan sistemas operativos tipo Unix) sepan qué programa usar para ejecutar un script. Diferentes scripts usan diferentes shebangs. Un shebang para un script bash se ve así:

#!/bin/bash

Si usa lo anterior como la primera línea de un script dado, bash generalmente se usará para ejecutar dicho script. Esto hará que sea mucho más difícil para alguien ejecutar accidentalmente el script con el shell incorrecto.

PD: No voy a mentir: hasta ahora, no sabía que se podía usar >&, pero, en lo que respecta a bash, parece hacer lo mismo &>. Tu aprendes algo nuevo cada dia.

Desde el Manual de referencia de Bash -> 3.6.4 Redirección de salida estándar y error estándar :

Esta construcción permite que tanto la salida estándar (descriptor de archivo 1) como la salida de error estándar (descriptor de archivo 2) se redirijan al archivo cuyo nombre es la expansión de la palabra.

Hay dos formatos para redirigir la salida estándar y el error estándar:

&>word

y

>&word

De las dos formas, se prefiere la primera. Esto es semánticamente equivalente a

>word 2>&1

Cuando se usa la segunda forma, la palabra no puede expandirse a un número o '-'. Si lo hace, se aplican otros operadores de redireccionamiento (consulte Duplicar descriptores de archivo a continuación) por razones de compatibilidad.

También es bueno consultar el wiki de Greg sobre Entrada y Salida -> 4.2. Manipulación del descriptor de archivo :

Para su comodidad, Bash también pone a su disposición otra forma de redireccionamiento. El operador de redirección &> es en realidad una versión más corta de lo que hicimos aquí [ 2>&1]; redirigiendo tanto stdout como stderr a un archivo.

Entonces, ¿por qué debo usar &> y no 2> & 1

2>&1 es el estándar Bourne / POSIX shell.

&>es una extensión bash y no estándar de jure .

Si escribes scripts usando extensiones bash, tarde o temprano te encontrarás con fallas que te rascarán la cabeza con mensajes de error de sintaxis críptica porque se ejecutan en un shell estándar.