Kabuğumun bir terminalde çalışıp çalışmadığını nasıl kontrol edebilirim?

Bazı işlemlerim sadece kabuğum bir terminale "bağlı" ise, yani sadece standart girişim bir terminalin girişinden geliyorsa ve standart çıktım (ve standart hata? Belki de önemli değil) basılıyor / yankılanıyorsa bazı işlemler yapmak istiyorum. bir terminal.

/proc/selfDoğrudan GNU / Linux özelliklerine (benzeri ) güvenmeden bunu nasıl yapabilirim ?

isattyBu kontrol için bir fonksiyondur ve -tbayrağı testkomutu bir kabuk o erişilebilir hale getirir:

-t file_descriptor

File tanımlayıcı numarası file_descriptor açıksa ve bir terminal ile ilişkilendirilmişse doğrudur . False file_descriptor geçerli bir dosya tanımlayıcı numarası değil ya da dosya tanıtıcı numarası ise file_descriptor açık değil, ya da açık ama bir terminal ile ilişkili değilse.

FD 0'ın (standart giriş) bir TTY olup olmadığını kontrol edebilirsiniz:

test -t 0

Çıkış ve hata akışlarını veya hepsini kontrol etmek için FD 1 ve 2 için aynı şeyi yapabilirsiniz:

test -t 0 -a -t 1 -a -t 2

Tanımlayıcılar bir terminale bağlıysa ve aksi takdirde yanlışsa, komut 0 değerini döndürür (başarılı olur).

test["braket testi" komutu olarak da mevcuttur :

 if [ -t 0 ] ; then ...

bu şartlı yazmak için deyimsel bir yoldur.

Bunun bir kopya olduğunu hayal ediyorum ama bulamıyorum. kullanım

[ -t 0 ]

ve

[ -t 1 ]

sırasıyla standart giriş ve çıkışın bir terminale bağlı olup olmadığını test etmek için. man testdetayları var.

Zaten verilen iyi cevapların üstüne sadece bir not. Not o [ -t 0 ]dosya tanıtıcı 0 açık bir (zararsız termio (ler) ioctl () başarılı olduğunu kontrol ederek yapılır tipik) bir tty çizgi disiplin olan bir cihazdır dosyasıdır bir dosyadır testler.

Ayrıca, bu mutlaka diğer ucunda bir terminal veya terminal emülatörü (klavyeye yazarak gerçek bir kullanıcı ile) olduğu anlamına gelmez (çoğu durumda ve muhtemelen umursadığınızların çoğunda olsa da, bu yeterince iyi bir yaklaşım).

tty ve pty aygıtları ayrıca veri aktarımı için veya işlemler arası iletişim mekanizması olarak da kullanılabilir.

Örneğin, bir yapabilirdi:

(stty raw -echo; myscript) < /dev/ttyS0

RS232’den alınanları beslemek için myscript.

echo test | ssh -tt host myscript

olurdu myscriptsitesindeki Stdin bir Pty cihaz olarak (ile sshd() SSH bağlantısı üzerinden bir uç, sonunda, diğer ucunda, ve ancak ile beslenen bir boru echo)

RS232 hattının veya ucunun diğer ucunda bir terminal olduğunu kontrol etmek için, bir $TERMdeğişkenin ayarlanıp boş olmadığını ( [ -n "$TERM" ]) kontrol edebilir ve bu fd üzerinden bir Aygıt Durum Raporu kaçış dizisi gönderebilir ve aldığınızı kontrol edebilirsiniz. (ek olarak bir cevap [ -t 0 ]ve [ -n "$TERM" ]).

printf >&0 '\e[5n'

\e[0nÇoğu terminal tarafından bir ile yanıtlanır .

Ben bunu tavsiye değildir bu yüzden Şimdi bu bazı sorunlar vardır o kontrol etmek istediğiniz durumlar dışında bu sen bu durumda, sizin gibi kütüphaneleri kullanarak daha iyi olurdu (görsel TUI uygulamayı çalıştırmak istiyor çünkü ncurses, ve DSR yerine, terminal türünü en doğru şekilde sorgulamak için bir cihaz tanımlama kaçış dizisi göndermeyi tercih edersiniz $TERM):

• Neyse ki, stdin'in bir terminal olmadığı çoğu durumda, salt okunur modda açık olacaktı, bu printfbaşarısızlığa neden olacaktı , ancak stdin, okuma + yazma modunda açık olan ve yan etkiye sahip bir tty cihazı ise bu diziyi diğer uca gönderme. Örneğin, yukarıdaki ssh örneğimizde, bu aslında diziyi bir terminale gönderir (ancak cevap stdin'e gelmeyecektir)
• Cevabı güvenilir ve taşınabilir bir şekilde okumak zor. Tty line disiplinini geçici olarak değiştirmeniz ve bir seferde bir byte okumanız gerekir. Ayrıca, eğer cevap görünmezse, pes edip terminal olmadığına karar vermeniz gereken bir zaman aşımına karar vermeniz gerekecektir. İnsanları uydu üzerinden bağlantı üzerinden çevirmeyi düşünmek istiyorsanız, bu uzun bir zaman aşımı demektir.
• Arka planda iken bir terminalden okumak, scriptinizi bir SIGTTIN sinyali ile askıya alacaktır.