redirigir COPIA de stdout al archivo de registro desde el script bash mismo

Sé cómo redirigir stdout a un archivo:

exec > foo.log
echo test

esto colocará la 'prueba' en el archivo foo.log.

Ahora quiero redirigir el resultado al archivo de registro Y mantenerlo en stdout

es decir, se puede hacer trivialmente desde fuera del script:

script | tee foo.log

pero quiero declararlo dentro del script mismo

Lo intenté

exec | tee foo.log

Pero no funcionó.

#!/usr/bin/env bash

# Redirect stdout ( > ) into a named pipe ( >() ) running "tee"
exec > >(tee -i logfile.txt)

# Without this, only stdout would be captured - i.e. your
# log file would not contain any error messages.
# SEE (and upvote) the answer by Adam Spiers, which keeps STDERR
# as a separate stream - I did not want to steal from him by simply
# adding his answer to mine.
exec 2>&1

echo "foo"
echo "bar" >&2

Tenga en cuenta que esto es bash, no sh. Si invoca el script con sh myscript.sh, obtendrá un error en la línea de syntax error near unexpected token '>'.

Si está trabajando con trampas de señal, es posible que desee utilizar la tee -iopción para evitar la interrupción de la salida si se produce una señal. (Gracias a JamesThomasMoon1979 por el comentario).

Herramientas que cambian su salida dependiendo de si escriben en una tubería o en un terminal (ls usando colores y salida en columnas, por ejemplo) detectarán la construcción anterior como que significa que salen a una tubería.

Hay opciones para aplicar la coloración / columna (p ls -C --color=always. Ej .). Tenga en cuenta que esto dará como resultado que los códigos de color se escriban también en el archivo de registro, lo que lo hará menos legible.

La respuesta aceptada no conserva STDERR como un descriptor de archivo separado. Eso significa

./script.sh >/dev/null

no saldrá bara la terminal, solo al archivo de registro, y

./script.sh 2>/dev/null

dará salida a ambos fooy baral terminal. Claramente, ese no es el comportamiento que un usuario normal probablemente espera. Esto se puede solucionar mediante el uso de dos procesos tee separados, ambos anexados al mismo archivo de registro:

#!/bin/bash

# See (and upvote) the comment by JamesThomasMoon1979 
# explaining the use of the -i option to tee.
exec >  >(tee -ia foo.log)
exec 2> >(tee -ia foo.log >&2)

echo "foo"
echo "bar" >&2

(Tenga en cuenta que lo anterior no trunca inicialmente el archivo de registro; si desea ese comportamiento, debe agregar

>foo.log

al principio del guión)

La especificación POSIX.1-2008 detee(1) requiere que la salida no esté almacenada, es decir, ni siquiera esté almacenada en línea, por lo que en este caso es posible que STDOUT y STDERR puedan terminar en la misma línea de foo.log; sin embargo, eso también podría suceder en el terminal, por lo que el archivo de registro será un fiel reflejo de lo que se puede ver en el terminal, si no un espejo exacto del mismo. Si desea que las líneas STDOUT se separen limpiamente de las líneas STDERR, considere usar dos archivos de registro, posiblemente con prefijos de sello de fecha en cada línea para permitir el reensamblaje cronológico más adelante.

Solución para busybox, macOS bash y shells que no son bash

La respuesta aceptada es sin duda la mejor opción para bash. Estoy trabajando en un entorno de Busybox sin acceso a bash, y no entiende la exec > >(tee log.txt)sintaxis. Tampoco lo haceexec >$PIPE correctamente, al intentar crear un archivo ordinario con el mismo nombre que la canalización con nombre, que falla y se bloquea.

Esperemos que esto sea útil para alguien más que no tenga bash.

Además, para cualquiera que use una tubería con nombre, es seguro rm $PIPE , porque eso desvincula la tubería del VFS, pero los procesos que la usan aún mantienen un recuento de referencia en ella hasta que finalizan.

Tenga en cuenta que el uso de $ * no es necesariamente seguro.

#!/bin/sh

if [ "$SELF_LOGGING" != "1" ]
then
    # The parent process will enter this branch and set up logging

    # Create a named piped for logging the child's output
    PIPE=tmp.fifo
    mkfifo $PIPE

    # Launch the child process with stdout redirected to the named pipe
    SELF_LOGGING=1 sh $0 $* >$PIPE &

    # Save PID of child process
    PID=$!

    # Launch tee in a separate process
    tee logfile <$PIPE &

    # Unlink $PIPE because the parent process no longer needs it
    rm $PIPE    

    # Wait for child process, which is running the rest of this script
    wait $PID

    # Return the error code from the child process
    exit $?
fi

# The rest of the script goes here

Dentro de su archivo de script, coloque todos los comandos entre paréntesis, de esta manera:

(
echo start
ls -l
echo end
) | tee foo.log

Manera fácil de hacer un registro de script bash en syslog. La salida del script está disponible tanto a través /var/log/syslogcomo a través de stderr. syslog agregará metadatos útiles, incluidas las marcas de tiempo.

Agregue esta línea en la parte superior:

exec &> >(logger -t myscript -s)

Alternativamente, envíe el registro a un archivo separado:

exec &> >(ts |tee -a /tmp/myscript.output >&2 )

Esto requiere moreutils(para el tscomando, que agrega marcas de tiempo).

Usando la respuesta aceptada, mi script siguió regresando excepcionalmente temprano (justo después de 'exec>> (tee ...)') dejando el resto de mi script ejecutándose en segundo plano. Como no pude lograr que esa solución funcionara a mi manera, encontré otra solución / solución al problema:

# Logging setup
logfile=mylogfile
mkfifo ${logfile}.pipe
tee < ${logfile}.pipe $logfile &
exec &> ${logfile}.pipe
rm ${logfile}.pipe

# Rest of my script

Esto hace que la salida del script pase del proceso, a través de la tubería hacia el proceso de fondo secundario de 'tee' que registra todo en el disco y en el stdout original del script.

Tenga en cuenta que 'exec &>' redirige tanto stdout como stderr, podríamos redirigirlos por separado si lo deseamos, o cambiar a 'exec>' si solo queremos stdout.

Incluso si la tubería se elimina del sistema de archivos al comienzo del script, continuará funcionando hasta que finalice el proceso. Simplemente no podemos hacer referencia a él usando el nombre del archivo después de la línea rm.

Bash 4 tiene un coproccomando que establece una canalización con nombre a un comando y le permite comunicarse a través de él.

No puedo decir que me sienta cómodo con ninguna de las soluciones basadas en exec. Prefiero usar tee directamente, por lo que hago que el script se llame a sí mismo con tee cuando lo solicite:

# my script: 

check_tee_output()
{
    # copy (append) stdout and stderr to log file if TEE is unset or true
    if [[ -z $TEE || "$TEE" == true ]]; then 
        echo '-------------------------------------------' >> log.txt
        echo '***' $(date) $0 $@ >> log.txt
        TEE=false $0 $@ 2>&1 | tee --append log.txt
        exit $?
    fi 
}

check_tee_output $@

rest of my script

Esto le permite hacer esto:

your_script.sh args           # tee 
TEE=true your_script.sh args  # tee 
TEE=false your_script.sh args # don't tee
export TEE=false
your_script.sh args           # tee

Puede personalizar esto, por ejemplo, hacer que tee = false sea el valor predeterminado en su lugar, hacer que TEE retenga el archivo de registro, etc. Supongo que esta solución es similar a la de jbarlow, pero más simple, tal vez la mía tiene limitaciones que aún no he encontrado.

Ninguno de estos es una solución perfecta, pero aquí hay un par de cosas que puedes probar:

exec >foo.log
tail -f foo.log &
# rest of your script

o

PIPE=tmp.fifo
mkfifo $PIPE
exec >$PIPE
tee foo.log <$PIPE &
# rest of your script
rm $PIPE

El segundo dejaría un archivo de tubería alrededor si algo sale mal con su script, lo que puede o no ser un problema (es decir, tal vez podría rmhacerlo en el shell principal después).