tmux sizin için gerçekten gerekli olmayabilir: Geliştirme iş akışında tmux’un yerine ne kullanılabilir?

 (bower.sh)
17 puan yazan GN⁺ 2025-08-04 | 7 yorum | WhatsApp'ta paylaş
  • Uzun süre tmux kullandı, ancak son dönemde tmux’un karmaşıklığı ve sınırlamaları (renk uyumluluğu, scrollback, fareyle kopyalama, protokol desteği eksikliği vb.) konusunda şüphe duymaya başladı
  • Oturum kalıcılığı (detach/attach) ya da pencere bölme/yönetimi gibi tmux’un temel işlevleri mutlaka yalnızca tmux ile sağlanmak zorunda değil
  • dtach, abduco, shpool gibi Unix felsefesine uygun hafif araçlar kullanılarak, yalnızca oturum yönetimine odaklanırken yerel scrollback ve sadelik de korunabiliyor
  • Özellikle shpool + ssh kombinasyonu ile birden fazla uzak oturumu doğrudan pencere yöneticisiyle yönetmek ve yerel özellikleri (bildirimler, kaydırma, başlıklar vb.) aynen kullanmak mümkün
  • Kusursuz olmasa da, yazarın ölçütlerine göre tmux’u tamamen değiştirebildi ve basit, bakımı kolay bir iş akışından memnun kaldı

tmux’un artıları ve eksileri

  • Oturum koruma (detach/attach), pencere yönetimi (sekmeler, split) gibi tmux’un sunduğu işlevler daha önce iş akışının merkezindeydi
  • Ancak doğru TERM ayarı olmadığında renk gösterim sorunları yaşanabiliyor ve terminal ile tmux arasındaki etkileşimi ayrıca düşünmek gerektiği için karmaşıklık artıyor
  • Scroll buffer kullanımı da tmux’a özgü ayrı bir yönteme alışmayı gerektiriyor; fareyle alan kopyalama da split ortamında rahatsız edici olabiliyordu
  • kitty graphics protocol gibi yeni terminal özellikleri için destek zayıf ve deneysel protokollerin desteklenmemesi gibi sorunlar da var
  • Escape code’ların tekrar yorumlanması ve oturum/pencere kavramlarının yeniden tanımlanması nedeniyle, çoklayıcıların terminal ekosisteminin gelişimini yavaşlattığı yönünde eleştiriler de bulunuyor

tmux’a alternatif yaklaşım arayışı

  • Oturum kalıcılığı:
    • Basitçe ctrl-z + fg, nohup, disown gibi yöntemler var, ancak tam bir ikame olmakta zorlanıyorlar
    • Yalnızca oturumu korumayı hedefleyen çeşitli araçlar (dtach, abduco, shpool) ortaya çıktı
      • fork() ve UNIX soketleri birleşimiyle daemon ile istemci arasında bağlantı kuruyorlar
      • tmux’tan farklı olarak sanal split olmadan yerel scrollback desteği sağlıyor, bazıları buffer geri yükleme özelliği de sunuyor
    • Deneyime göre, alternatif araçların çoğunda hatalar vardı ve nvim içinde detach kısayolunun çalışmaması gibi nedenlerle olgunluk düzeyi düşüktü
    • shpool, detach/attach komutları ve keymap özelleştirme açısından en olgun seçenekti
  • Pencere yönetimi:
    • Yerelde bölme ve yerleşim yönetimi pencere yöneticisiyle yapılıyor
    • Uzak (SSH) ortamda da ssh_config ile shpool birleştirilerek, birden fazla oturum ayrı pencerelerde bağımsız biçimde korunabiliyor
    • autossh ile birleştirildiğinde ağ yeniden bağlanmalarında da oturum korunuyor

Yeni iş akışı

  • Kişisel olarak pencere yönetimi için ghostty (dizüstü), sway+foot (kişisel PC) kullanıyor. Sunucular ise Proxmox tabanlı headless VM’ler ve SSH geliştirme ortamı her zaman açık
  • Birden fazla shpool oturumu, ssh kısayollarıyla otomatik bağlanacak şekilde ayarlanmış ve yerel pencere yöneticisinden bağımsız olarak kontrol ediliyor
    • ssh_config içinde her host için shpool oturumuna otomatik attach yapılandırılmış
    • Her terminalde IRC, dotfiles yönetimi, ayrı neovim ortamı gibi çoklu oturumlara ayrı ayrı bağlanmak mümkün
  • Yerel kaydırma, bildirimler, terminal başlığı gibi tmux’un kararsız destek verdiği işlevler artık daha doğal çalışıyor
  • Dezavantajlar da var: vim’e yeniden bağlanınca terminal durumunun toparlanması gecikiyor ve nvim kullanırken yeniden boyutlandırma sorunları görülüyor
    • Çok oyunculu kullanım desteklenmiyor (birden fazla istemcide aynı anda autossh çalışırsa oturum çakışabiliyor)
  • Buna rağmen kişisel ölçütlere göre tmux’un tamamen yerine geçti

Sonuç

  • Tam olarak aynı olmasa da, tmux’un karmaşıklığı ve sınırlamalarından uzaklaşıp daha basit ve esnek bir oturum yönetimi iş akışına geçmek mümkün
  • Kendi iş akışınıza göre shpool gibi alternatif araçları değerlendirmeye değer

İlgili okumalar

7 yorum

 
egirlasm 2025-08-05

Bugünlerde tmux gibi şeyleri yapay zekayla üretip kullanıyoruz. Xterm.js + react + electron ile 3-4 saatte böyle şeylerden 100 tane bile çıkarırsın; gerekirse gerçek zamanlı düzenleyip kullanırsın, adeta şabu şabu yer gibi — canın ne istiyorsa kaynağa bol bol eklersin.
 
barca105 2025-08-05

wezterm ile rahatça kullanıyorum
 
iolothebard 2025-08-04

Screen en iyisi!
 
helio 2025-08-04

cargo install shpool... ben yine tmux kullanacağım... her işletim sistemi için paketlerin hazır olması gerekiyor!
 
mineboo 2025-08-04

Zellij diye harika bir yeni oyuncu var. Kesinlikle tavsiye ederim.
 
xguru 2025-08-05

Zellij - geliştiriciler ve Ops için terminal

Bunu da epey uzun zaman önce paylaşmışım haha
 
GN⁺ 2025-08-04
Hacker News görüşü

  • Bu yazı Linux-on-the-Desktop kullanıcılarına yönelik olsa da, tmux'un asıl gücünü MacBook'ta iTerm2 ile birlikte kullanıldığında gösterdiğini vurgulamak isterim
    iTerm2'nin tmux entegrasyonu sayesinde tmux iş akışıma tamamen doğal biçimde karışıyor
    ~/.ssh/config içinde aşağıdaki gibi ayarlarsanız, MacBook'u yeniden açsanız ya da ağı değiştirseniz bile uzak geliştirme sunucusuna ssh ve tmux ile istediğiniz zaman kolayca erişebilirsiniz
    iTerm2 ve tmux entegrasyonu sayesinde uzak tmux sekmeleri ve scroll buffer, sanki yerel sekmelermiş gibi çalışıyor; hatta tmux komutlarını bilmeden bile kullanılabiliyor

    • Tüm kişisel cihazlarımda Linux kullanıyorum, iş içinse çoğunlukla MacBook kullanıyorum; tmux platformdan bağımsız olarak aynı ortamı yeniden üretmeyi sağladığı için gerçekten çok faydalı
      Linux'ta Alacritty kullanıyorum ama macOS'ta uygun ayarlar veya pencere/kaydırma farkları yüzünden hep bir şeyler tam oturmuyor
      Bu tür işletim sistemi farklarıyla vakit harcamak istemediğim için, tmux ve iTerm2 kombinasyonuyla Linux'a neredeyse aynı bir deneyim elde etmek iyi oluyor
      Oturum içi scrollback'in tamamen ayrı sunulması da benim için bir avantaj
      tmux'a yönelik eleştirilerin daha çok terminal geliştiricilerini ilgilendiren meseleler olduğunu düşünüyorum
      Destek yetersizse, daha iyi destek veren bir terminale geçmek yeterli

    • Ben mosh ve screen kombinasyonunu kullanıyorum
      Sunucu yeniden başlatılsa bile oturumu geri yükleyebiliyorum ve ağı değiştirsem de oturum kopmuyor
      Not: Immortal SSH Sessions

    • tmux'u onlarca kez denedim ama pek sevemedim, hep screen'e geri döndüm
      Ama bu ipucunu görünce bir kez daha denemek istedim

    • vim, tmux ve iTerm2 kombinasyonunda renk ve yazı tipi sorunlarıyla sık sık karşılaştım, sonunda yerelde tmux'tan vazgeçtim
      Güncellemelerden sağ çıkması ve oturumu koruması sayesinde elde ettiğim fayda da çok büyük değildi
      Yazı tipi sorunlarını çözebilirsem yeniden denemeye açığım ama şu an zamanım yok

    • Linux terminalleri arasında iTerm2 benzeri tmux entegrasyonu sunan bir şey olup olmadığını merak ediyorum
      Hâlâ GNU Screen kullanıyorum ama tmux'u bir kez daha denemeye hazırım

  • Bu blog yazısını okuyunca neden tmux kullandığımı bir kez daha hatırladım
    İnsanların tmux benzeri bir iş akışı kurmak için inanılmaz derecede çok uğraşması gerektiğini görünce, doğrudan tmux kullanmanın çok daha mantıklı olduğu anlaşılıyor
    Bazen kopyala-yapıştır biraz rahatsız edici olabiliyor ama bunu pek dert etmiyorum
    'Multiplexer gereksiz ek yük oluşturuyor' eleştirisi, kod tabanının bakımını yapan biri değilseniz pek umursamanız gereken bir şey değil

    • Kopyala-yapıştır sorunu yalnızca tmux'a özgü değil
      vim gibi tüm terminali doğrudan çizen uygulamaların hepsinde ortaya çıkabiliyor
      OSC52 adlı terminal escape sequence ile bu sorun kolayca çözülebilir
      Aşağıdaki basit Python betiğini kullanırsanız grep sonuçlarını bile doğrudan sistem panosuna gönderebilirsiniz
      tmux ve nvim zaten OSC52 desteği sunuyor; başka yerlerde de kolayca kullanılabilir

    • Bu arada tmux'a bir PR göndermiştim; maintainer Nick Marriott'un iletişimi gerçekten çok iyiydi, bu da hoşuma gitti
      Kod da oldukça düzenli ve tmux daha iyi hale geldi

    • Olmayan bir sorunu zorla varmış gibi gösteren bu tür tartışmalardan yoruldum
      Yazarın sunduğu gerekçeler bana ikna edici gelmiyor; hatta onun "7 yılı aşkın tmux deneyimi" iddiası bile şüpheli hissettiriyor

  • Tmux'u birkaç hafta önce öğrendim ve belirli pane'lere programatik olarak tuş girdisi gönderebilme olasılığı beni büyüledi
    Japon bir forumdan ilham alarak Claude Code'un (bundan sonra CC) etkileşim gerektiren CLI betikleriyle doğrudan etkileşime girip giremeyeceğini düşündüm ve bunu Tmux ile yapmanın mümkün olduğunu doğruladım
    Bunun üzerine claude-code-tools adında küçük bir araç yaptım; böylece CC gibi CLI ajanları Tmux pane'leri oluşturabiliyor, içlerinde betik çalıştırabiliyor ve gerçek zamanlı etkileşime girebiliyor
    Bir bakıma Playwright veya Puppeteer'ın terminal sürümü gibi
    claude-code-tools GitHub bağlantısı
    Bu yöntemle CC, etkileşim gerektiren CLI betiklerini otomatik test edebilir; başka bir pane'de arayüz açıp Puppeteer MCP ile tarayıcı üzerinden test yapabilir, debugger'ı etkinleştirip breakpoint koyabilir, çoklu ajan entegrasyonları kurabilir ve daha pek çok şey yapabilir
    Bu tür genişletilebilirliğin tmux alternatif araçlarda da uygulanıp uygulanamayacağını merak ediyorum

    • Not olarak, screen'de de stuff komutuyla pane'lere programatik biçimde tuş girdisi gönderebilirsiniz

    • Bu yöntemle Claude Code, Gemini CLI ve OpenCode gibi çeşitli CC örneklerini interactive modda kontrol edebiliyor
      Böylece geleneksel alt ajanlardan farklı bir entegrasyon türü mümkün oluyor

    • tmux-cli wrapper'ın gerçekten sonuçları iyileştirip iyileştirmediğini merak ediyorum
      Ben Claude'a mevcut tmux komutlarını kullanmasını söylediğimde gayet iyi çalışıyor; bu yüzden ayrı bir Bash kullanmadan tüm komutları tmux oturumu içinde çalıştırmasını sağlıyorum

    • Bunu terminal düzeyinde daha kolay yapmak istiyorsanız Kitty'nin remote control özelliği de harika
      Kitty Remote Control tanıtımı

    • Terminal özünde bir file descriptor'dan ibaret olduğu için, script(1), expect(1), chat(8) gibi benzer araçlar 80'lerden beri vardı
      Yani ille de tmux şart değil

  • tmux'ta TERM ayarını düzgün yapmazsanız renkler gibi şeylerin doğru görüntülenmemesi sorunu, aslında tüm terminal emülatörleri/programlarında da görülen aynı sorundur
    Unix ve Linux sistemlerinde TERM ile terminfo/termcap kavramları işin özüdür; dolayısıyla doğru yapılandırma şarttır
    Bu, tmux'a özgü bir sorun değil

    • Ama yazarın suçu tmux'a yüklemesi üzücü
      Kaydırma sorununun da gerçekten tmux'un sorunu olup olmadığı şüpheli; tmux alternate screen buffer kullanır ve bu, viewport taban çizgisini netleştirerek imleç hareketini kolaylaştırmak için getirilmiştir
      Modern terminallerin çoğu alternate screen durumunda bile yerel kaydırmaya izin verdiği için bu özellik artık tam korunmuyor

    • Çoğu program da varsayılan ayarlar doğru yapılmadığında beklendiği gibi çalışmaz
      tmux örneğinde sorun şu ki "neden" hemen anlaşılmıyor; ama çözümün ne olması gerektiği de belirsiz kalıyor (örneğin varsayılanı 256colors yapmak gibi mi?)

    • Doğru, ama tmux kullanırken dikkat edilmesi gereken bir katman daha eklenmiş oluyor
      tmux'un içinde tmux'a özel TERM, dışında ise kullandığınız terminale uygun TERM kullanılmalı
      tmux FAQ'ya bakarsanız görüntüleme sorunlarının çoğunun TERM yanlış ayarından kaynaklandığını görürsünüz

  • "Multiplexer gereksiz ek yük getiriyor" eleştirisi aslında benim tmux'u tercih etme nedenim
    termcap desteğini bırakan uygulamaların arttığı bugünkü ortamda, tmux sayesinde VT520 gibi eski terminallerimde bile uygulamaları çalıştırabiliyorum
    Herhangi bir terminal geliştiricisinin tmux'tan hoşlanmaması beni pek ilgilendirmiyor
    Sonuçta kullanıcı açısından mimari zarafetten çok düzgün çalışması önemli
    Bu arada kişisel olarak alacritty'nin daha iyi olduğunu düşünüyorum (ama en çok Konsole kullanıyorum)

    • VT520'ye sahip olmanızı kıskandığımı söylemeliyim
      Uzun zamandır VT525 arıyorum ama hem pahalı hem de satıcıların çoğu yurt dışında
      genuine VT525 üzerinde nosh realizer'ın iyi çalışıp çalışmadığını hep merak etmişimdir
      tmux ortadan kalksa bile, TERM ile hafif uyumsuz uygulamalar başka yollarla transliterate edilebilir

    • Benim VT420'm donanımsal akış kontrolünü desteklemiyor; bu yüzden yazılımsal akış kontrolü kullanmam gerekiyor ve bu yöntem modern terminal uygulamalarıyla pek iyi anlaşmıyor
      GNU Screen bu konuda son derece iyi bir çözüm sunuyor; ayrıca başka pek çok özelliği de var
      tmux'u modern emülatörlerde çok kullandım ama eski terminallerde bu kritik akış kontrolü özelliğinin eksik olduğunu düşünüyorum
      termcap/terminfo desteklemeyen uygulamaları idare etmek için tmux'un faydalı olduğu görüşüne katılıyorum

    • alacritty'nin neden daha iyi olduğunu düşündüğünüzü merak ediyorum
      Eski donanımda açılışı yavaş, sekme gibi pratik özellikleri eksik ve benchmark'larda bile kitty/ghostty/konsole/foot'un gerisinde kalıyor
      Buna rağmen insanların bir nedenle alacritty kullanmaya devam etmesi ilginç geliyor

  • Hâlâ tmux kullanmayı planlıyorum
    Birden fazla proje arasında oturum yönetimi ve yeniden başlatma sonrası oturumu geri yükleme kolay olduğu için hoşuma gidiyor
    mouse ile copy/paste tarafında da tmux-yank sayesinde hiç sorun yaşamadım
    Yıllardır aynı ortamı kullanıyorum
    tmux'un send-keys özelliğiyle, dotfile'larımı refactor ederken birden çok pane/oturumda alias veya yapılandırma dosyalarını aynı anda güncelleyip nvim'i yeniden başlatan otomasyonlar kurdum
    Bu deneyimi blog yazısı ve videoda anlattım

  • Ben "you might not need tmux" tartışmasını "you might not need browser tabs" tartışmasına benzetiyorum
    Bir veya iki terminal oturumu ya da web sayfası için belki gerekli olmayabilir, ama bunun ötesine geçtiğinizde pencere yönetimi aşırı zahmetli hale geliyor ve sonunda aynı özellikleri yeniden kurmaya başlıyorsunuz

    • Bu aralar kullandığım window manager'ın pencere yönetimi özelliklerinden olabildiğince yararlanmaya çalışıyorum
      Tarayıcı sekmeleri, terminal sekmeleri veya tmux yerine pencere yerleşimi, sekme yönetimi ve yer imlerini window manager'a bırakınca benim için yeterli oluyor

    • Sekme yönetimini uygulamaların değil, window manager'ın üstlenmesi gerektiğine neredeyse inanç düzeyinde bağlandım
      Benim window manager'ım pencereleri tile edebiliyor ya da üst üste duran pencereleri sekmeli gruplar halinde toplayabiliyor
      Bu sekmeler aynı uygulamadan da olabilir, farklı uygulamalardan da

    • Tarayıcı sekmelerini farklı pencerelere ayırmak veya tekrar birleştirmek kolay; ama tmux sekmeleri bu açıdan yeterince esnek değil
      İyi bir window manager, sekmeleri ve pencereleri özgürce yeniden birleştirmenize izin verir

    • Benim tmux yapılandırmamda tıklanabilir sekmeler var

    • MS Windows'un çoklu pencere yönetimi (Alt Tab, Win Tab vb.) gerçekten çok iyi
      Her terminale farklı ikon/arka plan rengi vererek ayırt ediyorum ve işletim sistemi pencere yönetimi işinin büyük kısmını zaten üstleniyor
      Mac de kullandım ama bu konuda Windows kadar tatmin edici bulmadım

  • Buffer scrollback gibi tmux hakkında şikâyet edilen şeyler, tam tersine benim tmux kullanma motivasyonum
    İkinci dizüstü bilgisayarım eski bir Debian terminal makinesi ve fare çalışmıyor; dolayısıyla kopyala-yapıştırı yalnızca tmux ile yapabiliyorum
    Benim için tmux'un yerine geçecek bir şey yok

    • tmux capture-pane - | vim - kombinasyonu bazen fare tekerleğiyle kaydırmaktan daha kullanışlı oluyor

  • suckless tarafı, terminal tasarlarken tmux benzeri özellikleri bilerek eklememek gibi tam tersi bir yaklaşım benimsiyor
    Bkz: st.suckless.org/goals

    • Geliştirme felsefesi açısından suckless ile Kitty'nin tam zıt kutuplar olduğu söylenebilir

  • Kitty'nin terminal emülatörlerinin geleceğine yön verebileceğini düşünüyorum ve başarılı olmasını isterim
    Ancak Kitty'yi iş için kullanamıyorum; tmux olmadan oturumlar, pencere düzeni, durum, kopyalama buffer'ı ve scrollback'in hepsi kaybolduğu için ondan vazgeçmem mümkün değil
    Windows'ta uygun bir alternatif çıkana kadar, yanında Kitty kullansam bile işte tmux kullanmaya devam edeceğim

    • Kitty'yi ben de kısa süre kullandım ve tmux ayarlarıma benzer bir ortamı yeniden üretebilmesi etkileyiciydi
      Ama sonunda yine tmux ve varsayılan terminal kombinasyonuna döndüm
      Her yerde çalışması ve araçları birleştirerek kullanma yaklaşımının daha kalıcı olması nedeniyle tmux hâlâ en iyi seçenek