Wie erkenne ich, ob mein Shell-Skript durch eine Pipe läuft?

Wie erkenne ich in einem Shell-Skript, ob seine Standardausgabe an ein Terminal gesendet oder an einen anderen Prozess weitergeleitet wird?

Das Beispiel: Ich möchte Escape-Codes hinzufügen, um die Ausgabe einzufärben, aber nur, wenn sie interaktiv ausgeführt werden, aber nicht, wenn sie weitergeleitet werden, ähnlich wie dies der ls --colorFall ist.

In einer reinen POSIX-Shell

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

Gibt "Terminal" zurück, da die Ausgabe an Ihr Terminal gesendet wird

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

Gibt "kein Terminal" zurück, da die Ausgabe der Klammer an weitergeleitet wird cat.

Die -tFlagge wird in Manpages als beschrieben

-t fd True, wenn der Dateideskriptor fd geöffnet ist und auf ein Terminal verweist.

... wo fdkann eine der üblichen Dateideskriptorzuweisungen sein:

0:     stdin  
1:     stdout  
2:     stderr

Es gibt keine narrensichere Methode, um festzustellen, ob STDIN, STDOUT oder STDERR zu / von Ihrem Skript geleitet werden, hauptsächlich aufgrund von Programmen wie ssh.

Dinge, die "normal" funktionieren

Die folgende Bash-Lösung funktioniert beispielsweise in einer interaktiven Shell ordnungsgemäß:

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

Aber sie funktionieren nicht immer

Wenn Sie diesen Befehl jedoch als Nicht-TTY- sshBefehl ausführen , sehen STD-Streams immer so aus, als würden sie weitergeleitet. Um dies zu demonstrieren, verwenden Sie STDIN, weil es einfacher ist:

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

Warum es wichtig ist

Dies ist eine ziemlich große Sache, da es impliziert, dass ein Bash-Skript nicht erkennen kann, ob ein Nicht-Tty- sshBefehl weitergeleitet wird oder nicht. Beachten Sie, dass dieses unglückliche Verhalten eingeführt wurde, als neuere Versionen von sshPipes für Nicht-TTY-STDIO verwendet wurden. In früheren Versionen wurden Sockets verwendet, die durch Verwendung von Bash innerhalb von Bash unterschieden werden KÖNNTEN [[ -S ]].

Wenn es darauf ankommt

Diese Einschränkung verursacht normalerweise Probleme, wenn Sie ein Bash-Skript schreiben möchten, dessen Verhalten einem kompilierten Dienstprogramm ähnelt, z cat. Zum Beispiel catermöglicht es die folgenden flexible Verhalten gleichzeitig verschiedene Eingangsquellen in der Handhabung und ist intelligent genug , um zu bestimmen , ob es verrohrt Eingang unabhängig davon empfängt , ob nicht-TTY TTY oder Zwang sshverwendet wird:

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

Sie können so etwas nur tun, wenn Sie zuverlässig feststellen können, ob Rohre betroffen sind oder nicht. Andernfalls führt das Ausführen eines Befehls, der STDIN liest, wenn keine Eingabe von Pipes oder Umleitungen verfügbar ist, dazu, dass das Skript hängt und auf die STDIN-Eingabe wartet.

Andere Dinge, die nicht funktionieren

Bei dem Versuch, dieses Problem zu lösen, habe ich mir verschiedene Techniken angesehen, die das Problem nicht lösen können, einschließlich solcher, die Folgendes umfassen:

• Untersuchen von SSH-Umgebungsvariablen
• Verwenden statvon Dateideskriptoren für / dev / stdin
• Untersuchen des interaktiven Modus über [[ "${-}" =~ 'i' ]]
• Prüfung des Status über ttyundtty -s
• sshStatus prüfen über[[ "$(ps -o comm= -p $PPID)" =~ 'sshd' ]]

Beachten Sie, dass /procSie möglicherweise Glück haben , wenn Sie ein Betriebssystem verwenden, das das virtuelle Dateisystem unterstützt, indem Sie den symbolischen Links für STDIO folgen, um festzustellen, ob eine Pipe verwendet wird oder nicht. Es handelt sich jedoch /procnicht um eine plattformübergreifende POSIX-kompatible Lösung.

Ich bin äußerst interessant bei der Lösung dieses Problems. Lassen Sie mich wissen, wenn Sie an eine andere Technik denken, die möglicherweise funktioniert, vorzugsweise POSIX-basierte Lösungen, die sowohl unter Linux als auch unter BSD funktionieren.

Der Befehl test(integriert bash) bietet eine Option zum Überprüfen, ob ein Dateideskriptor ein tty ist.

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

Siehe " man test" oder " man bash" und suchen Sie nach " -t"

Sie erwähnen nicht, welche Shell Sie verwenden, aber in Bash können Sie dies tun:

#!/bin/bash

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

Unter Solaris funktioniert der Vorschlag von Dejay Clayton hauptsächlich. Das -p reagiert nicht wie gewünscht.

bash_redir_test.sh sieht aus wie:

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

Unter Linux funktioniert es hervorragend:

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

Unter 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

:# 

Der folgende Code (nur in Linux Bash 4.4 getestet) sollte weder als portabel angesehen noch empfohlen werden. Der Vollständigkeit halber ist er jedoch hier:

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

Ich weiß nicht warum, aber es scheint, dass der Dateideskriptor "3" irgendwie erstellt wird, wenn eine Bash-Funktion STDIN-Piping hat.

Ich hoffe es hilft,