Як визначити, чи мій скрипт оболонки працює через трубу?

Як я можу виявити зсередини скрипт оболонки, якщо його стандартний вихід надсилається до терміналу або якщо він передається в інший процес?

Справжній випадок: я хотів би додати коди евакуації, щоб розфарбувати вихід, але лише тоді, коли вони запускаються в інтерактивному режимі, але не в трубопроводі, як ls --colorце робиться.

У чистої оболонці POSIX,

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

повертає "термінал", оскільки вихід надсилається на ваш термінал, тоді як

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

повертає "не термінал", тому що висновок дужки проходить до cat.

-tПрапор описаний в людино - сторінках , як

-t fd True, якщо дескриптор файлу fd відкритий і посилається на термінал.

... де fdможе бути одне із звичайних призначень дескрипторів файлів:

0:     stdin  
1:     stdout  
2:     stderr

Не існує надійного способу визначити, чи STDIN, STDOUT або STDERR переносяться на / з вашого сценарію, в першу чергу через такі програми ssh.

Речі, які "нормально" працюють

Наприклад, наступне рішення bash працює правильно в інтерактивній оболонці:

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

Але вони не завжди працюють

Однак, виконуючи цю команду як команду не TTY ssh, потоки STD завжди виглядають так, як вони переносяться. Щоб продемонструвати це, використовуючи STDIN, оскільки це простіше:

# 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 ${?}'

Чому це важливо

Це досить велика справа, оскільки це означає, що для скрипту bash немає способу сказати, чи є нетипізована sshкоманда в трубі чи ні. Зауважте, що ця нещасна поведінка була введена, коли останні версії sshпочали використовувати труби для не TTY STDIO. У попередніх версіях використовувалися сокети, які МОЖЕ бути диференційовані з башти за допомогою використання [[ -S ]].

Коли це має значення

Це обмеження зазвичай викликає проблеми, коли ви хочете написати скрипт bash, який має поведінку, схожу на компільовану утиліту, наприклад cat. Наприклад, catдозволяє наступну гнучку поведінку в обробці різних джерел входу одночасно, і досить розумна, щоб визначити, чи приймає він трубопровідний вхід незалежно від того, використовується не-TTY або примусово-TTY ssh:

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

Ви можете зробити щось подібне лише в тому випадку, якщо зможете достовірно визначити, задіяні труби чи ні. В іншому випадку виконання команди, яка зчитує STDIN, коли вхід не доступний ні з труб, ні з перенаправлення, призведе до того, що сценарій зависне і чекає введення STDIN.

Інші речі, які не працюють

Намагаючись вирішити цю проблему, я розглянув кілька методів, які не вирішили проблему, включаючи такі, які включають:

• вивчення змінних середовища SSH
• за допомогою statдескрипторів файлів on / dev / stdin
• вивчення інтерактивного режиму через [[ "${-}" =~ 'i' ]]
• вивчення статусу tty через ttyтаtty -s
• вивчення sshстатусу через[[ "$(ps -o comm= -p $PPID)" =~ 'sshd' ]]

Зауважте, що якщо ви використовуєте ОС, яка підтримує /procвіртуальну файлову систему, вам, можливо, пощастить, перейшовши на символічні посилання для STDIO, щоб визначити, використовується труба чи ні. Однак /procце не крос-платформене, сумісне з POSIX рішення.

Мені надзвичайно цікаво вирішити цю проблему, тому, будь ласка, повідомте мене, якщо ви думаєте про будь-яку іншу техніку, яка могла б працювати, бажано на POSIX-рішеннях, які працюють як на Linux, так і на BSD.

Команда test(вбудована bash) має можливість перевірити, чи є дескриптор файлу tty.

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

Дивіться " man test" або " man bash" та шукайте " -t"

Ви не згадуєте, яку оболонку використовуєте, але в Bash ви можете це зробити:

#!/bin/bash

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

Щодо Solaris, пропозиція від Dejay Clayton працює в основному. -P не відповідає за бажанням.

bash_redir_test.sh виглядає так:

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

У Linux це чудово працює:

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

На 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

:# 

Наступний код (перевірений лише у Linux bash 4.4) не слід вважати переносним і не рекомендується , але заради повноти тут він є:

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

Я не знаю чому, але здається, що дескриптор файлу "3" якимось чином створюється, коли у функції bash є STDIN.

Сподіваюся, це допоможе,