Como detectar se meu script de shell está executando através de um pipe?

Como detectar de dentro de um script de shell se sua saída padrão está sendo enviada para um terminal ou se é canalizada para outro processo?

O caso em questão: eu gostaria de adicionar códigos de escape para colorir a saída, mas apenas quando executados de forma interativa, mas não quando canalizados, semelhante ao que ls --colorfaz.

Em um shell POSIX puro,

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

retorna "terminal", porque a saída é enviada ao seu terminal, enquanto

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

retorna "não um terminal", porque a saída do parêntese é canalizada para cat.

O -tsinalizador é descrito nas páginas do manual como

-t fd True se o descritor de arquivo fd estiver aberto e se referir a um terminal.

... onde fdpode ser uma das atribuições usuais de descritor de arquivo:

0:     stdin  
1:     stdout  
2:     stderr

Não há uma maneira infalível de determinar se STDIN, STDOUT ou STDERR estão sendo canalizados para / do seu script, principalmente por causa de programas como o ssh.

Coisas que "normalmente" funcionam

Por exemplo, a seguinte solução do bash funciona corretamente em um shell interativo:

[[ -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'

Mas eles nem sempre funcionam

No entanto, ao executar este comando como um comando não-TTY ssh, os fluxos STD sempre parecem estar sendo canalizados. Para demonstrar isso, use STDIN porque é mais 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 isso importa

Isso é muito importante, porque implica que não há como um script bash dizer se um sshcomando não-tty está sendo canalizado ou não. Observe que esse comportamento infeliz foi introduzido quando versões recentes de sshcomeçaram a usar pipes para STDIO não-TTY. As versões anteriores usavam soquetes, que PODEM ser diferenciados de dentro do bash usando [[ -S ]].

Quando importa

Essa limitação normalmente causa problemas quando você deseja escrever um script bash com comportamento semelhante a um utilitário compilado, como cat. Por exemplo, catpermite o seguinte comportamento flexível ao lidar com várias fontes de entrada simultaneamente e é inteligente o suficiente para determinar se está recebendo entrada canalizada, independentemente de não sshestar sendo usado TTY ou forçado :

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

Você só pode fazer algo assim se puder determinar com segurança se os tubos estão envolvidos ou não. Caso contrário, a execução de um comando que lê STDIN quando nenhuma entrada está disponível nos pipes ou redirecionamentos resultará na interrupção do script e na espera pela entrada STDIN.

Outras coisas que não funcionam

Ao tentar resolver esse problema, observei várias técnicas que não conseguem resolver o problema, incluindo aquelas que envolvem:

• examinando variáveis ​​de ambiente SSH
• usando statdescritores de arquivo / dev / stdin
• examinando o modo interativo via [[ "${-}" =~ 'i' ]]
• examinando o status tty via ttyetty -s
• examinando o sshstatus via[[ "$(ps -o comm= -p $PPID)" =~ 'sshd' ]]

Observe que, se você estiver usando um sistema operacional compatível com o /procsistema de arquivos virtual, poderá ter sorte seguindo os links simbólicos do STDIO para determinar se um pipe está sendo usado ou não. No entanto, /procnão é uma solução compatível com POSIX multiplataforma.

Eu sou extremamente interessante na solução desse problema, então, deixe-me saber se você pensa em alguma outra técnica que possa funcionar, de preferência soluções baseadas em POSIX que funcionem no Linux e no BSD.

O comando test(embutido bash), tem uma opção para verificar se um descritor de arquivo é um tty.

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

Veja " man test" ou " man bash" e procure por " -t"

Você não menciona qual shell está usando, mas no Bash, você pode fazer isso:

#!/bin/bash

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

No Solaris, a sugestão de Dejay Clayton funciona principalmente. O -p não responde conforme desejado.

bash_redir_test.sh se parece com:

[[ -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'

No Linux, funciona muito bem:

:$ ./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

No 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

:# 

O código a seguir (testado apenas no linux bash 4.4) não deve ser considerado portátil nem recomendado , mas por uma questão de integridade, aqui está:

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

Não sei por que, mas parece que o descritor de arquivo "3" é criado de alguma forma quando uma função bash tem STDIN canalizado.

Espero que ajude,