Uzun zamandır yoğun bir Screen kullanıcısı oldum, ancak 2002'de değiştirdiğim bir sürümünü kullanıyorum. Çoğunlukla, gezinme sırasına göre "sonraki / önceki" penceresinin yeni olduğu sırayla eşleşmesini istediğim için istedim. pencereler, i3 veya Ion gibi bir döşeme penceresi yöneticisine benzer şekilde oluşturuldu . Standart Ekran davranışı 'sonraki' ve 'önceki' için pencere numarasına göredir, bu nedenle genellikle 'yeni' bir pencere (mevcut olan en küçük sayıyı kaplayan) 'sonraki' pencereden başka bir yere yerleştirilir - yapmazsanız kafa karıştırıcıdır. Numaraları hatırlamıyorum. Tercih ettiğim davranış o zamandan beri Tmux’ta 2010’da yeni pencere komutuna ve 2012’de yeniden numaralandırma pencerelerine bayrak olarak uygulandı.. Belgelendirme ekleri ve diğerleri de dahil olmak üzere mümkün olduğunca kabul etmeye çalıştığım Screen yamam, Temmuz 2002'de Screen listesinde herhangi bir tartışma yapmadı (daha sonra "screen@informatik.uni-erlangen.de", arşiv bulmak). Aslında, bir yıl sonra tekrar gönderdiğimde bile onaylanmadı.
2002'den beri, ekranın daha yeni sürümlerine uygulamak için düzeltme ekimi birkaç kez "yeniden yapıyorum". Ancak, 4.3 sürümüne (2015) ulaştığımda, ekran kullanımlarımdan birini bozan belgesiz bir değişiklik olduğunu fark ettim - yani 'şeyler' şu anda çevre değişkenleriyle iç içe geçiyor . Bu özelliğe ihtiyacım olmadı ve argümandan 'eşyalara' kolayca nasıl kaçabileceğimi bulamadım (böylece dolar işareti içeren metinler gönderebildim) bu yüzden 4.0 sürümünü kullanmaya devam ettim (2004'ten itibaren).
Ekranın 'eşyalarını' (Tmux'ta 'send-keys'), geçerli Emac bölgesi içeriğini belirli bir pencere numarasına gönderen bir Emacs işlevinde kullanırım. Bu şekilde bir kodlama dilinde kod yazarken, bir tercüman açarım, tercüman penceresine özel bir sayı veririm ve sonra bu Emacs bağlamasını kullanarak editör penceremden doğrudan tercüman penceresine kod satırları gönderebilirim. Zorlu ama saf Emacs çözümünden daha çok hoşlanıyorum , çünkü standart tuş vuruşlarını kullanarak Tercüman ile Ekran penceresindeki etkileşimde bulunabiliyorum. Biraz GUI IDE'ye benziyor, ancak fareyi kullanmam veya yanıp sönen bir imlece bakmam gerekmiyor.
Düzeltme ekimde uyguladığım bir diğer özellik, bir pencereyi "işaretleme" ve ardından işaretlenmiş pencereyi geçerli pencereden sonra "sonraki" olacak şekilde yeniden konumlandırma yeteneğidir. Benim için bu, pencereleri yeniden sıralamaktan daha doğal bir yöntemdir; kopyala / yapıştır paradigması veya "sürükle ve bırak" gibidir. ( Son zamanlarda bunun i3'te nasıl yapıldığını da çözdüm .)
Aynı şeyi Tmux'da da yapmak mümkün olmalı, örneğin 2015'ten itibaren bir bölmeyi "işaretlemek" için bir tesis var. Veya belki de daha temel bir çözüm, durumsal kabuk senaryoları ile çözülebilir. "İşaretli bölme" yöntemini denemek için kısa bir komut dosyası ve anahtar kelimeler kullandım ve birkaç kez işe yaradı, ancak Tmux "[kayıp sunucu]" ile düştü. Sonra Tmux’un karmaşık bir şey yapmaya çalışmadan bile çökmesini sağladım. Görünüşe göre , bazı kullanıcılar için en azından birkaç yıldır çöküyor . Bazen sunucu çöküyor, bazen CPU'nun% 100'ünü kullanmaya başlıyor ve yanıt vermiyor. Bunların ikisini de Screen'i hiç görmedim.
Teoride, Tmux birçok açıdan Ekrandan üstündür. Komut satırından Windows listesini sorgulamak gibi şeyleri yapabileceğiniz anlamına gelen çok daha iyi bir komut dosyası yazılabilirliğine sahiptir; bu, Ekran ile imkansızdır. Örneğin, 2015 Ekranı'nda "pencereleri başlığa göre sıralamak" için bir komut eklendi . Böyle özel bir komutun ne zaman faydalı olacağından emin değilim, ancak bu ve daha pratik varyasyonlar (örn. CPU kullanımı ile sıralama pencereleri) Tmux'taki bir kabuk betiğinden nispeten kolayca yapılabilir. Bana göre en azından C kodunu değiştirmeden Ekranda çok yaratıcı bir şey yapmak zor gözüküyor.
Diğer afişlerde de belirtildiği gibi, Tmux, özellikle sunucu kilitlenirken birincil dezavantaj olarak gördüğüm tek sunucu modeline sahiptir. Her "oturum" için ayrı bir soket belirleyerek bu sorunu çözmek mümkündür. Yine de Screen'in oturum başına bir sunucu varsayılanını tercih ediyorum, bu biraz daha şık görünüyor.
2002 yılında, Ekran kodu ile çalışmak benim için eğitici ve zevkliydi. İşin garibi, tüm ek özellikleri için, Tmux'un Ekrandan% 30 daha az kod satırı var (30k - 40k). Tmux’un birçok ağaç kullandığını ve veri yapılarını listelediğini fark ettim, bu benim için biraz zordu. Ekran dizileri tercih ediyor gibiydi.
Anladığım kadarıyla, Unix terminal arayüzü çok kararlı olduğundan, temel işletim sistemindeki değişikliklere uyum sağlamak için Ekran veya Tmux koduna çok az ihtiyaç vardır. Bu programlar gerçekten web tarayıcıları veya web sunucuları veya hatta kabuk gibi güvenlik güncellemelerine sahip değildir. Ekranımın özel sürümünü çalıştırırken, en son 2004’de güncellenen herhangi bir sorun fark etmedim ( Systemd’in soketi silmesini engellemek için bazı yapılandırma dosyaları eklememe gerekliliği dışında); Bu dosyalar genellikle zaten dağıtım paketinin bir parçasıdır). Belki de çökmeye başlamadan önceki Tmux sürümünü çalıştırarak Tmux'ta karşılaştığım sorunları çözebilirdim. Tabii ki, eğer yeterince kullanıcı bunu yaparsa, yeni kullanıcılar için çok iyi olmayacak, çünkü bu programların en son resmi sürümlerinde daha az uzmanın hata arayacağı anlamına geliyor. Ancak benim için dengesiz olan (en son Tmux) veya istediğim bazı özelliklere sahip olmayan (standart Ekran) bir ürüne geçmem için kendimi motive etmek zor.
Bunun OP'nin sorusuna kolay bir cevap vermediğini biliyorum, ancak bakış açımın yararlı olduğunu umuyorum.