¿Cómo detectar si mi script de shell se ejecuta a través de una tubería?

¿Cómo detecto desde un script de shell si su salida estándar se envía a un terminal o si se canaliza a otro proceso?

El caso en cuestión: me gustaría agregar códigos de escape para colorear la salida, pero solo cuando se ejecuta de forma interactiva, pero no cuando se canaliza, de forma similar a lo que ls --colorhace.

En un shell POSIX puro,

if [ -t 1 ] ; then echo terminal; else echo "not a terminal"; fi

devuelve "terminal", porque la salida se envía a su terminal, mientras que

(if [ -t 1 ] ; then echo terminal; else echo "not a terminal"; fi) | cat

devuelve "no un terminal", porque la salida del paréntesis se canaliza a cat.

La -tbandera se describe en las páginas del manual como

-t fd Verdadero si el descriptor de archivo fd está abierto y hace referencia a un terminal.

... donde fdpuede ser una de las asignaciones de descriptor de archivo habituales:

0:     stdin  
1:     stdout  
2:     stderr

No hay una forma infalible de determinar si STDIN, STDOUT o STDERR se están canalizando hacia / desde su script, principalmente debido a programas como ssh.

Cosas que "normalmente" funcionan

Por ejemplo, la siguiente solución bash funciona correctamente en un shell interactivo:

[[ -t 1 ]] && \
    echo 'STDOUT is attached to TTY'

[[ -p /dev/stdout ]] && \
    echo 'STDOUT is attached to a pipe'

[[ ! -t 1 && ! -p /dev/stdout ]] && \
    echo 'STDOUT is attached to a redirection'

Pero no siempre funcionan

Sin embargo, al ejecutar este comando como un comando que no es TTY ssh, las transmisiones STD siempre parecen estar siendo canalizadas. Para demostrar esto, use STDIN porque es más fácil:

# CORRECT: Forced-tty mode correctly reports '1', which represents
# no pipe.
ssh -t localhost '[[ -p /dev/stdin ]]; echo ${?}'

# CORRECT: Issuing a piped command in forced-tty mode correctly
# reports '0', which represents a pipe.
ssh -t localhost 'echo hi | [[ -p /dev/stdin ]]; echo ${?}'

# INCORRECT: Non-tty mode reports '0', which represents a pipe,
# even though one isn't specified here.
ssh -T localhost '[[ -p /dev/stdin ]]; echo ${?}'

Por que es importante

Este es un gran problema, porque implica que no hay forma de que un script bash sepa si un sshcomando que no es tty se está canalizando o no. Tenga en cuenta que este comportamiento desafortunado se introdujo cuando las versiones recientes de sshcomenzaron a utilizar tuberías para STDIO no TTY. Las versiones anteriores usaban sockets, que PODRÍAN diferenciarse desde dentro de bash usando [[ -S ]].

Cuando importa

Esta limitación normalmente causa problemas cuando desea escribir un script bash que tenga un comportamiento similar a una utilidad compilada, como cat. Por ejemplo, catpermite el siguiente comportamiento flexible en el manejo de varias fuentes de entrada simultáneamente, y es lo suficientemente inteligente como para determinar si está recibiendo una entrada canalizada independientemente de si sshse está utilizando TTY no forzado o TTY forzado :

ssh -t localhost 'echo piped | cat - <( echo substituted )'
ssh -T localhost 'echo piped | cat - <( echo substituted )'

Solo puede hacer algo así si puede determinar de manera confiable si las tuberías están involucradas o no. De lo contrario, la ejecución de un comando que lee STDIN cuando no hay entrada disponible desde cualquiera de las tuberías o la redirección dará como resultado que el script se cuelgue y espere la entrada de STDIN.

Otras cosas que no funcionan

Al tratar de resolver este problema, he examinado varias técnicas que no logran resolverlo, incluidas las que incluyen:

• examinar las variables de entorno SSH
• utilizando statdescriptores de archivo on / dev / stdin
• examinar el modo interactivo a través de [[ "${-}" =~ 'i' ]]
• examinar el estado de tty a través de ttyytty -s
• examinar el sshestado a través de[[ "$(ps -o comm= -p $PPID)" =~ 'sshd' ]]

Tenga en cuenta que si está utilizando un sistema operativo que admite el /procsistema de archivos virtual, es posible que tenga suerte siguiendo los enlaces simbólicos de STDIO para determinar si se está utilizando una tubería o no. Sin embargo, /procno es una solución multiplataforma compatible con POSIX.

Soy extremadamente interesante para resolver este problema, así que avíseme si piensa en alguna otra técnica que pueda funcionar, preferiblemente soluciones basadas en POSIX que funcionen tanto en Linux como en BSD.

El comando test(incorporado bash) tiene una opción para verificar si un descriptor de archivo es un tty.

if [ -t 1 ]; then
    # stdout is a tty
fi

Ver " man test" o " man bash" y buscar " -t"

No mencionas qué shell estás usando, pero en Bash, puedes hacer esto:

#!/bin/bash

if [[ -t 1 ]]; then
    # stdout is a terminal
else
    # stdout is not a terminal
fi

En Solaris, la sugerencia de Dejay Clayton funciona principalmente. La -p no responde como se desea.

bash_redir_test.sh se parece a:

[[ -t 1 ]] && \
    echo 'STDOUT is attached to TTY'

[[ -p /dev/stdout ]] && \
    echo 'STDOUT is attached to a pipe'

[[ ! -t 1 && ! -p /dev/stdout ]] && \
    echo 'STDOUT is attached to a redirection'

En Linux, funciona muy bien:

:$ ./bash_redir_test.sh
STDOUT is attached to TTY

:$ ./bash_redir_test.sh | xargs echo
STDOUT is attached to a pipe

:$ rm bash_redir_test.log 
:$ ./bash_redir_test.sh >> bash_redir_test.log

:$ tail bash_redir_test.log 
STDOUT is attached to a redirection

En Solaris:

:# ./bash_redir_test.sh
STDOUT is attached to TTY

:# ./bash_redir_test.sh | xargs echo
STDOUT is attached to a redirection

:# rm bash_redir_test.log 
bash_redir_test.log: No such file or directory

:# ./bash_redir_test.sh >> bash_redir_test.log
:# tail bash_redir_test.log 
STDOUT is attached to a redirection

:# 

El siguiente código (probado solo en linux bash 4.4) no debe considerarse portátil ni recomendado , pero en aras de la exhaustividad aquí es:

ls /proc/$$/fdinfo/* >/dev/null 2>&1 || grep -q 'flags: 00$' /proc/$$/fdinfo/0 && echo "pipe detected"

No sé por qué, pero parece que el descriptor de archivo "3" se crea de alguna manera cuando una función bash tiene STDIN canalizado.

Espero eso ayude,