Bir tmux bölmesini “yeniden başlatmak” için kolay bir yol var mı?

47

Aşağıdaki tmuxgibi bölünmüş bir (1.7) pencerem olduğunu varsayalım :

 ________________________
|           1            |
|                        |
|-----------+------------|
|     2     |      3     |
|___________|____________|

Şimdi, dikey boyutlar özelleştirildi, bu nedenle hiçbir şekilde varsayılan mizanpajlardan biri değil.

Bazı durumlarda, bir program sıkışırsa veya bağlandığınız bir makineyi yeniden başlattığınızda ssh, bölme "kilitlenir". Yani kill-paneişe göründüğünden başka bir şey yok .

Bununla birlikte, bölme 1 kill-paned kez bölünmüş yapılandırmanın üzerinde yeniden oluşturmanın kolay bir yolu olmadığından, bölme 1 d olduğunda "yeniden başlatmak" istiyorum.

tmux

— 0xC0000022L
kaynak

81

Kılavuza bakıldığında, komut respawn-panebana vurdu, ancak bunun işe yaramadığı ortaya çıktı. Daha yakından respawn-pane -kokumak, cevabın o olduğunu gösterdi, çünkü çalışan komutu öldürürdü .

Bu şekilde bir bölme "yeniden başlatılabilir" ve yeniden yerine yerleştirilebilir.

Yani <prefix>+ :ve sonra girin respawn-pane -kveEnter

— 0xC0000022L
kaynak

4

Ya -kda bölmeyi remain-on-exitkipte oluşturup komutu kendiniz öldürdüyseniz kullanın.

— Peterph,

yeniden

— doğduysanız

4

Aslında, düzeni yeniden oluşturmanın bir yolu vardır - list-windowssize bir oturumdaki tüm pencereler için bir düzen açıklaması verir select-layoutve dizeyi ayrıştırıp sindirmeyi düzenleyebilir ve düzeni uygun şekilde ayarlayabilir ( select-layoutman sayfasına bakın tmux(1)).

Ssh sorununuza gelince - ssh sunucuları, sistem kapandığında bağlantıyı kapatmalıdır (her ne kadar ssh daemon'unu kapatmadan ve oturumları düzgün bir şekilde çalıştırarak uygun davranışı bozan bazı Linux dağıtımları görmeme rağmen) - bu durumda, bkz ESCAPE CHARACTERSbölümüne (ve buna atıfta başka yerlerde) ssh(1)tarafından takip kaçış karakteri - .zorla istemci tarafında bağlantıyı sonlandırır (nokta). Tabii, içinde sshçalışan bölmeyi yumurtlamanızın bir faydası olmaz , ancak sorunu daha sık karşılaşırsanız, belki de bölmede bir kabuk çalıştırmak ve oradan ssh çağırmak istersiniz.

— peterph
kaynak

Cevabınızı yükselttim, çünkü değer katıyor. Fakat işte bu, kaçış karakterlerinin mutlaka iyi bir fikir olmadığının nedeni: açık ssh bağlantısı olan bir tmux oturumuna bağlanmak için ssh oturumu kullanmak. Sonra aniden kaçış karakterinin ilk ssh bağlantısının ötesine nasıl içine ulaşacağını göndermeyi düşünmeniz gerekir. Ve btw, genellikle kabuktan ssh kullanırım.

— 0xC0000022L

1

Neredeyse iç içe tmux seansları yaptığınız zamankiyle aynı şey. Dış ve iç oturumda farklı kaçış karakterleriniz var (ssh ya da tmux olsun) ya da iki kez kaçış karakterini gönderirsiniz - bu onu yuvalanmış oturuma tek bir karakter olarak gönderir (ssh için yapılandırılmış kablolu davranış, tmux'da).

— Peterph,