TL; DR
Kabuk vs Terminal
Açıklığa kavuşturmamız gereken ilk şey, tam olarak ne istendiğidir - çalışan kabuğu veya çalışan terminali bulun. Genellikle bu iki terim birbirinin yerine kullanılır, ancak bunlar tamamen farklı şeylerdir. Kabuk komut satırı yorumlayıcısıdır, özellikle etkileşimli kabuk komutları girdiğiniz komut istemi artı metin alanıdır. Kabuklar etkileşimli olmayabilir, örneğin bir komut dosyası etkileşimli olmayan kabuğu bash -c 'echo hello world'başlatır veya etkileşimli olmayan kabuğu başlatır.
Aksine, terminal kabuğa arayüzdür (yine de başka bir uygulama da olabilir). Başlangıçta terminal gerçek donanıma atıfta bulundu, ancak bugünlerde çoğunlukla yazılım. GUI'deki Ctrl+ Alt+ tuşlarına bastığınızda tveya terminal simgesine tıkladığınızda, bir terminal emülatörü, donanımın davranışını taklit eden bir pencere başlatır ve bu pencerede kabuğun çalıştığını görebilirsiniz. Ctrl+ Alt+ F2(veya 6 işlev tuşundan herhangi biri) sanal konsolu, aka açacaktır tty. Okumayı öneririm Neden sanal bir terminal "sanal" ve "gerçek" terminal neyin / niçin / nerede? özellikleri hakkında daha fazla bilgi için.
Kabuk bilgisini almak
Her kullanıcının /etc/passwdkendi kullanıcı adı için kendisine atanmış varsayılan bir kabuğu vardır . Varsayılan yapılandırma kullandığınızı ve açıkça bir komut olarak başka bir kabuk çağırmadığınızı varsayalım:
echo $SHELL
Fakat elbette bu sadece varsayılan değeri gösterir . Aşağıdakileri yaptığımızı varsayalım:
user@ubuntu:~$ dash
$
Biz başlangıçta vardı bash, ama etkileşimli oturumu başladı /bin/dash, Ubuntu'nun POSIX veya sistem kabuğu . Değişken $SHELLdeğişmez, çünkü amacı bu değil - varsayılan değeri değil mevcut değeri gösterir. Buna başka bir perspektiften yaklaşmamız gerekecek - içinde ele aldığım şey olan sürecin perspektifi bash veya sh kullanıyor muyum?
$ echo $$
4824
$ cat /proc/4824/comm
mksh
$ bash
xieerqi@eagle:~$ echo $$
6197
xieerqi@eagle:~$ cat /proc/6197/comm
bash
Burada /proc/dosya sisteminden faydalanıyoruz . İşlemin adı ve komut satırı parametreleri içinde gösterilir /proc/<pid>/comm. Tek ihtiyacımız olan, kabuğun PID'sini sağlamak $$. Yukarıdaki örnekte, bunu ayrı olarak ekliyorum, fakat bizi sadece yapmaktan alıkoyacak hiçbir şey yok.
cat /proc/$$/comm
Temadaki çeşitlilik de olabilir.
ps -p $$ -o args
Buna yaklaşabilmemizin bir başka yolu da nerede olduğunu kontrol etmek /proc/<pid>/exe. Bu dosya çalıştırılabilir dosyaya işaret eden bir bağlantıdır. Böylece yapabiliriz
user@ubuntu:~$ ls -l /proc/$$/exe
lrwxrwxrwx 1 adminx adminx 0 Apr 4 18:20 /proc/1241/exe -> /bin/bash
user@ubuntu:~$ sh
$ ls -l /proc/$$/exe
lrwxrwxrwx 1 adminx adminx 0 Apr 4 18:20 /proc/1255/exe -> /bin/dash
İki yaklaşımdan biri vakaların% 99'unda işe yarıyor. Tabii ki, onların yıkılmalarının yolları var. Örneğin, symlink, çalıştırılabilir kabuk başlatıldıktan kısa bir süre sonra silinirse hiçbir yere işaret etmez (ve bu durumda muhtemelen, sistem komutlarıyla karşılaşırsınız, çünkü bunları kaldırmanız /bin/sh, /bin/dashhatta /bin/bashönerilmemeniz - çoğu komut dosyası bunlara dayanır) , özellikle sistem düzeyinde olanlar). Kabuk için komut adı genellikle execve()syscall'deki ilk argüman olarak ayarlanır . Bu, bash'ın nasıl kullanıldığını nasıl biliyor? , Bir kabuk aracılığıyla başlatan bir uygulamanız varsa execve(), herhangi bir isim verebilir. Ancak bunlar standart olmayan ve tipik olmayan şeylerdir, tutarlılık ve güvenlik açısından kaçınılması gerekenler.
Terminal Bilgilerini Alma
Çevre değişkenleriyle başlayabiliriz. Birçok terminal kendilerini veya xtermtarafından bildirilen uyumlu olarak maskeliyor gibi görünmektedir . Ancak o zaman çevre değişkenleri çok güvenilir bir araç değildir. Ayarlanabilir ve ayarlanamazlar. Aynı şeyi PID'lerle de tekrar yapabiliriz, ancak bu sefer ebeveyn PID'e bakacağız. Hatırlayabileceğiniz gibi, terminal kabuğun arayüzüdür ve sıklıkla kabuğun kendisini başlatır. Bu nedenle, kabuğumuzun ana işleminin hangi işlem olduğunu öğrenebiliriz:echo $TERMecho $COLORTERM
$ ps -p $$ -o args,ppid
COMMAND PPID
bash 1234
$ ps -p 1234 -o args
COMMAND
/usr/lib/gnome-terminal/gnome-terminal-server
Başka bir terminal uygulamasıyla deneyelim sakura:
$ ps -p $$ -o args,ppid
COMMAND PPID
/bin/bash 16950
$ ps -p 16950 -o args
COMMAND
sakura
Oradan, bu kabuğun neyin başladığını zaten görebiliyoruz gnome-terminal. Elbette bu yöntem, etkileşimli kabuk ile çalıştığınızı varsayıyor. Örneğin, üst öğenin ebeveyni bash -c '...'veya kabuğunu bulmaya çalışıyorsak ssh, PID, terminal olmayan bir uygulamadan ve belki de GUI dışı olabilir.
Öyleyse, GUI terminali ile özel olarak ilgilenmek istiyorsak, yapabileceğimiz şey çalıştırılır xprop, istenen pencereye tıklayın, iadesini alın ve bu işlemin eşleştirme işleminin adının ne olduğunu bulun. Veya başka bir deyişle:
$ ps aux | grep $(xprop | awk -F'=' '/PID/ {print $2}')
xieerqi 2124 0.6 1.7 208068 34604 ? Sl 18:47 1:49 gnome-terminal
Ek olarak, spesifikasyonlara göre , pencere yöneticileri WM_CLASSözelliği belirlemelidir . Böylece bunu da alabiliriz xprop:
$ xprop WM_CLASS
WM_CLASS(STRING) = "sakura", "Sakura"
Tabii ki, bu aynı zamanda% 1 dezavantajına sahiptir: ayarlama WM_CLASSözellikleri bunu yapan pencere yöneticisine dayanır ve karmaşık bir hata ayıklamayı içerebilecek bir pencerenin doğru olması için PID'nin garantisi yoktur (bkz. Bu X11 penceresini hangi süreç oluşturdu? ). Bunlar, yöntemlerin kendisinde değil, X11 sunucusunda eksiklikler değil. Bununla birlikte, çoğu kararlı ve iyi bilinen pencere yöneticileri (openbox, Metacity, blackbox gibi) ve çoğu uygulama iyi davrandığından, Gnome Terminal veya Terminator gibi bir şeyle ilgili sorunlar beklememeliyiz.
Fakat GUI terminal emülatörlerine gelince, bir komut bulmamız bile gerekmiyor. Sadece Aboutpencerenin kendi diyalog penceresini kullanabiliriz . Bu kuralın istisnası xterm.