significa - redirigir salidas linux

Después de usar `exec 1> file`, ¿cómo puedo detener esta redirección de STDOUT al archivo y restablecer el funcionamiento normal de STDOUT?

Question

Soy un novato en scripting shell y estoy usando Ubuntu-11.10. En la terminal después de usar exec 1>file comando exec 1>file , cualquier comando que dé al terminal, su salida no se muestra en la terminal. Sé que STDOUT se redirecciona al archivo, la salida de esos comandos se redirige al archivo.

Mis preguntas estan aqui

1. Una vez que utilizo el exec 1>file , ¿cómo puedo deshacerme de esto? es decir, ¿cómo puedo detener la redirección de STDOUT al archivo y restablecer el funcionamiento normal de STDOUT (es decir, redireccionar al terminal en lugar de al archivo)?

   Intenté usar exec 1>&- pero no funcionó ya que esto cierra el descriptor de archivo STDOUT.

2. Por favor, arroje luz sobre toda esta operación de exec 1>file y exec 1>&-

3. ¿Qué pasará si cerramos los descriptores de archivos estándar 0, 1, 2 usando exec 0>&- exec 1>&- exec 2>&- ?

Answer 1

Q1

Debe prepararse para la recuperación antes de realizar el primer exec :

exec 3>&1 1>file

Para recuperar el resultado estándar original más tarde:

exec 1>&3 3>&-

El primer exec copia el descriptor de archivo original 1 (salida estándar) al descriptor de archivo 3, luego redirige la salida estándar al archivo nombrado. El segundo exec copia el descriptor de archivo 3 a la salida estándar nuevamente y luego cierra el descriptor de archivo 3.

Q2

Esto es un poco abierto. Puede describirse en un nivel de código C o en el nivel de línea de comandos del shell.

exec 1>file

simplemente redirige la salida estándar (1) del shell al archivo nombrado. El descriptor de archivo uno ahora hace referencia al archivo nombrado; cualquier salida escrita en salida estándar irá al archivo. (Tenga en cuenta que las solicitudes en un shell interactivo se escriben en un error estándar, no en un resultado estándar).

exec 1>&-

simplemente cierra la salida estándar del shell. Ahora no hay un archivo abierto para salida estándar. Los programas pueden alterarse si se ejecutan sin salida estándar.

Q3

Si cierra los tres de entrada estándar, salida estándar y error estándar, un shell interactivo saldrá cuando cierre la entrada estándar (porque obtendrá EOF cuando lea el próximo comando). Se continuará ejecutando un script de shell, pero los programas que ejecuta pueden alterarse porque están garantizados 3 canales de archivos abiertos - entrada estándar, salida estándar, error estándar - y cuando su shell los ejecuta, si no hay otra redirección de E / S , entonces no obtienen los canales de archivos que les fueron prometidos y todo el infierno se puede desatar (y la única forma en que sabrá es que el estado de salida del comando probablemente no sea cero - éxito).

Answer 2

Aunque estoy totalmente de acuerdo con el Q1 de Jonathan, algunos sistemas tienen /dev/stdout , por lo que es posible que pueda exec 1>file; ...; exec 1>/dev/stdout exec 1>file; ...; exec 1>/dev/stdout

Answer 3

Q1 : hay una manera simple de restaurar stdout al terminal después de haber sido redirigido a un archivo:

exec >/dev/tty

Aunque normalmente se requiere guardar el descriptor original del archivo stdout para que se restaure más adelante, en este caso particular, desea que stdout sea /dev/tty por lo que no es necesario hacer más.

$ date
Mon Aug 25 10:06:46 CEST 2014
$ exec > /tmp/foo
$ date
$ exec > /dev/tty
$ date
Mon Aug 25 10:07:24 CEST 2014
$ ls -l /tmp/foo
-rw-r--r-- 1 jlliagre jlliagre 30 Aug 25 10:07 /tmp/foo
$ cat /tmp/foo
Mon Aug 25 10:07:05 CEST 2014

Q2 : el exec 1>file es una forma un poco más prolija de exec >file que, como ya se mencionó, redirige el stdout al archivo dado, siempre que tenga el derecho de crearlo / escribirlo. El archivo se crea si no existe, se trunca si lo hace.

exec 1>&- está cerrando la salida estándar, que probablemente sea una mala idea en la mayoría de las situaciones.

Q3 : los comandos deben ser

exec 0<&-
exec 1>&-
exec 2>&-

Tenga en cuenta la redirección inversa para stdin.

Puede ser simplificado de esa manera:

exec <&- >&- 2>&-

Este comando cierra los tres descriptores de archivos estándar. Esta es una muy mala idea. Si desea que un script se desconecte de estos canales, sugeriría este enfoque más sólido:

exec </dev/null >/dev/null 2>&1

En ese caso, todos los resultados se descartarán en lugar de desencadenar un error, y toda la entrada devolverá solo nada en lugar de fallar.

Answer 4

La respuesta aceptada es demasiado detallada para mí. Entonces, decidí resumir una respuesta a tu respuesta original.

Usando Bash versión 4.3.39 (2) -release

En un x86 de 32 bits en Cygwin Machine

DADO:

• Stdin es fd # 0.
• Stdout es fd # 1.
• Stderr es fd # 2.

RESPUESTA (escrita en bash):

exec 1> ./output.test.txt
echo -e "First Line: Hello World!"
printf "%s/n" "2nd Line: Hello Earth!" "3rd Line: Hello Solar System!"

# This is uneccessary, but
# it stops or closes stdout.
# exec 1>&-

# Send stdout back to stdin
exec 1>&0

# Oops... I need to append some more data.
# So, lets append to the file.
exec 1>> ./output.test.txt
echo -e "# Appended this line and the next line is empty./n"

# Send stdout back to stdin
exec 1>&0

# Output the contents to stdout
cat ./output.test.txt

PALABRAS CLAVE ÚTILES:

También hay here-docs, here-strings y process-substitution para redirección de IO en Bourne, Bash, tcsh, zsh para Linux, BSD, AIX, HP, Busybox, Toybox y otros.