¿Es seguro redirigir stdout y stderr al mismo archivo sin copias del descriptor de archivo?

Comienzo en el directorio vacío.

$ touch aFile
$ ls
aFile

Luego tengo lsdos argumentos, uno de los cuales no está en este directorio. Redirijo ambas secuencias de salida a un archivo llamado output. Lo uso >>para evitar escribir simultáneamente.

$ ls aFile not_exist >>output 2>>output
$ cat output
ls: cannot access 'not_exist': No such file or directory
aFile

Lo que parece funcionar. ¿Hay algún peligro para este enfoque?

No, no es tan seguro como el estándar >>bar 2>&1.

Cuando estas escribiendo

foo >>bar 2>>bar

está abriendo el bararchivo dos veces O_APPEND, creando dos objetos de archivo completamente independientes [1], cada uno con su propio estado (puntero, modos abiertos, etc.).

Esto es muy diferente a lo 2>&1que simplemente está llamando a la llamada del dup(2)sistema, y ​​hace que los alias intercambiables stderr y stdout para el mismo objeto de archivo.

Ahora, hay un problema con eso:

O_APPENDpuede conducir a archivos corruptos en los sistemas de archivos NFS si más de un proceso agrega datos a un archivo a la vez. Esto se debe a que NFS no admite la adición de un archivo, por lo que el núcleo del cliente tiene que simularlo, lo que no se puede hacer sin una condición de carrera.

Generalmente, usted puede contar con la probabilidad de que el archivo como baren el foo >>bar 2>&1que se escriben en, al mismo tiempo desde dos lugares separados siendo bastante bajo. Pero por su >>bar 2>>barsolo lo aumentó en una docena de órdenes de magnitud, sin ninguna razón.

[1] "Descripciones de archivos abiertos" en la jerga POSIX.

¿Qué pasa cuando lo haces?

some_command >>file 2>>file

es que filese abrirá para agregar dos veces. Esto es seguro en un sistema de archivos POSIX. Cualquier escritura que le ocurra al archivo cuando se abre para agregarla ocurrirá al final del archivo, independientemente de si los datos provienen del flujo de salida estándar o del flujo de error estándar.

Esto se basa en el soporte para operaciones de escritura de adición atómica en el sistema de archivos subyacente. Algunos sistemas de archivos, como NFS, no admiten el agregado atómico. Consulte, por ejemplo, la pregunta "¿El archivo se agrega atómico en UNIX?" En StackOverflow.

Utilizando

some_command >>file 2>&1

funcionaría incluso en NFS sin embargo.

Sin embargo, usando

some_command >file 2>file

no es seguro, ya que el shell truncará el archivo de salida (dos veces) y cualquier escritura que ocurra en cualquiera de las secuencias sobrescribirá los datos ya escritos por la otra secuencia.

Ejemplo:

$ { echo hello; echo abc >&2; } >file 2>file
$ cat file
abc
o

La hellocadena se escribe primero (con una nueva línea de terminación), y luego la cadena abcseguida de una nueva línea se escribe a partir del error estándar, sobrescribiendo el hell. El resultado es la cadena abccon una nueva línea, seguida de lo que queda de la primera echosalida, una oy una nueva línea.

Intercambiar los dos echoalrededor de la herida produce solo helloen el archivo de salida, ya que esa cadena se escribe en último lugar y es más larga que la abccadena. El orden en que ocurren las redirecciones no importa.

Sería mejor y más seguro usar los más idiomáticos.

some_command >file 2>&1

Depende de lo que quieras lograr. Depende de usted decidir si está bien tener errores en el mismo archivo que la salida. Esto es solo guardar texto en un archivo con la funcionalidad del shell que le permite redirigir como lo desee. No hay un sí o un no absoluto. Como todo en Linux se puede hacer de varias maneras, esta es mi forma de ls notExistingFile existingFile >> output 2>&1 responder la pregunta: en términos de la redirección en sí, sí, es perfectamente seguro.