シェルが端末に「接続」されている場合にのみアクションを実行します。つまり、標準入力が端末の入力から来て、標準出力(および標準エラーですか?ターミナル。
GNU / Linuxの詳細(など/proc/self
)に直接依存せずに、どうすればそれができますか?
シェルが端末に「接続」されている場合にのみアクションを実行します。つまり、標準入力が端末の入力から来て、標準出力(および標準エラーですか?ターミナル。
GNU / Linuxの詳細(など/proc/self
)に直接依存せずに、どうすればそれができますか?
回答:
isatty
これはチェックするための関数で-t
あり、test
コマンドのフラグはシェルスクリプトからアクセスできるようにします。
-t file_descriptor
ファイル記述子番号file_descriptorが開いており、端末に関連付けられている場合は真。falseの場合file_descriptorが有効なファイルディスクリプタの番号ではないか、ファイルディスクリプタ数の場合file_descriptorが開いていない、またはそれは開いているが、端末に関連付けられていない場合。
以下を使用して、FD 0(標準入力)がTTYであるかどうかを確認できます。
test -t 0
FD 1とFDについても同じことを実行して、出力ストリームとエラーストリーム、またはそれらすべてをチェックできます。
test -t 0 -a -t 1 -a -t 2
記述子が端末に接続されている場合、コマンドは0(成功)を返し、そうでない場合はfalseを返します。
test
[
「ブラケットテスト」のコマンドとしても使用できます。
if [ -t 0 ] ; then ...
は、この条件を記述する慣用的な方法です。
これは複製だと思いますが、見つけられません。つかいます
[ -t 0 ]
そして
[ -t 1 ]
標準入力と標準出力が端末に接続されているかどうかをそれぞれテストします。man test
詳細があります。
既に与えられている細かい答えの上に、追加のメモを追加します。[ -t 0 ]
ファイル記述子0がtty行規則を持つデバイスファイルであるファイルを開くことをテストすることに注意してください(通常、無害なtermio(s)ioctl()が成功することを確認することによって行われます)。
また、それは必ずしも反対側に端末または端末エミュレーター(実際のユーザーがキーボードで入力する)があることを意味するわけではありません(ただし、非常に多くの場合、そしておそらくあなたが気にするもののほとんどは、それで十分です)近似値)。
ttyおよびptyデバイスは、データ転送またはプロセス間通信メカニズムとしても使用できます。
たとえば、次のことができます。
(stty raw -echo; myscript) < /dev/ttyS0
RS232経由で受信したものをに送信するにはmyscript
。
echo test | ssh -tt host myscript
なければならないmyscript
のPTYデバイスであるSTDIN(とsshd
他の端部において、最終的に(SSH接続を介して)いない端末が、によって供給パイプecho
)
そのRS232回線またはptyのもう一方の端に端末があることをさらに確認するには、$TERM
変数が設定されて空でないことを確認し([ -n "$TERM" ]
)、そのfdを介してデバイスステータスレポートエスケープシーケンスを送信し、受信したことを確認することもできます応答([ -t 0 ]
およびに加えて[ -n "$TERM" ]
)。
printf >&0 '\e[5n'
\e[0n
ほとんどの端末で応答されます。
これにはいくつかの問題がありますので、視覚的なTUIアプリケーションを実行するために確認したい場合を除いて、それを行うことはお勧めしません(その場合はncurses
、また、DSRの代わりに、デバイス識別エスケープシーケンスを送信して、端末のタイプをより正確に照会したい場合もあります$TERM
)。
printf
失敗する読み取り専用モードで開かれていますが、stdinが読み取り+書き込みモードで開かれているttyデバイスの場合、副作用がありますそのシーケンスをもう一方の端に送信する。たとえば、上記のsshの例では、シーケンスを実際に端末に送信します(ただし、応答はstdinには届きません)