2011-01-06 15:20:23 +0000 2011-01-06 15:20:23 +0000
284
284

tmux vs. screen

Zamierzam wrócić do używania GNU Screen , ale słyszałem, że ludzie od czasu do czasu wspominają o tmux jako lepszej alternatywie. Czy rzeczywiście oferuje on alternatywę dla wszystkich funkcji, które oferuje Screen , takich jak monitorowanie aktywności w różnych oknach, itp. Jakie są plusy i minusy każdego z nich?

Odpowiedzi (9)

177
177
177
2011-01-17 20:36:07 +0000

Niektóre z (głównych) powodów, dla których wolę tmux od screen:

  • Pasek stanu jest znacznie łatwiejszy w użyciu. Możesz łatwo ustawić różne teksty/style dla bieżącego okna, okien z aktywnością, itp. i możesz umieścić rzeczy po lewej i prawej stronie paska statusu, w tym polecenia powłoki, które mogą być uruchamiane w określonym odstępie czasu (domyślnie 15s).
  • Prawie każde polecenie, które można uruchomić wewnątrz tmux może być uruchomione z powłoki z tmux command [args]. To czyni go bardzo łatwo skryptowalnym, jak również ułatwia wykonywanie złożonych poleceń.
  • Znacznie dokładniejsza automatyczna zmiana nazw okien. Podczas gdy screen ustawia tytuł na podstawie pierwszego słowa komendy i wymaga konfiguracji powłoki, aby nawet to zrobić w oknie powłoki, tmux śledzi jakie procesy są faktycznie uruchomione w każdym oknie i odpowiednio aktualizuje tytuł. W ten sposób otrzymujesz dynamiczną zmianę nazw z dowolną powłoką i zerową konfiguracją. Na przykład: Powiedzmy, że używasz Z Shell; nazwa okna będzie brzmiała “zsh”. Teraz powiedzmy, że chcesz edytować jakiś plik konfiguracyjny, więc wpisujesz sudo emacs /etc/somefile. Podczas gdy sudo pyta o hasło, nazwa okna będzie brzmiała “sudo”, ale gdy już to zrobisz i sudo uruchomi emacs, nazwa będzie brzmiała “emacs”. Kiedy skończysz i wyjdziesz z emacs, tytuł zmieni się z powrotem na “zsh”. Jest to całkiem przydatne do śledzenia okien, a także może być szczególnie przydatne w specyficznych sytuacjach, jak na przykład, gdy masz jakiś długo działający proces w innym oknie, który od czasu do czasu prosi cię o wejście przy użyciu dialog; nazwa okna zmieni się na “dialog”, gdy to się stanie, więc będziesz wiedział, że musisz przełączyć się do tego okna i coś zrobić.
  • Ładniejsza obsługa sesji (IMHO). Możesz zrobić o wiele więcej z sesjami w samym tmux. Możesz łatwo przełączać, zmieniać nazwy itp. i możesz przenosić i dzielić okna między sesjami. Ma również inny model, w którym każdy użytkownik ma serwer, który kontroluje jego sesje i do którego łączy się klient. Wadą tego jest to, że jeśli serwer się zawiesi, tracisz wszystko; nigdy nie miałem awarii serwera na mnie, chociaż.
  • tmux wydaje się być bardziej aktywnie rozwijany. Aktualizacje pojawiają się dość często, a ty możesz złożyć raport o błędach lub prośbę o funkcję zgodnie z tym FAQ i otrzymać odpowiedź w ciągu kilku dni.

To są tylko główne rzeczy, które natychmiast przychodzą na myśl. Są też inne małe rzeczy i jestem pewien, że o niektórych zapomniałem. Jednak zdecydowanie warto spróbować tmux.

100
100
100
2011-05-04 18:28:02 +0000

(Sesje są zbiorami okien, które można odłączyć i ponownie dołączyć później. Okna mogą zawierać jeden lub więcej panes. Dla przykładowych configów, sprawdź tutaj i tutaj ).

tmux

  • Plusy
  • Może wysyłać klawisze do innych paneli, trochę jak IDE
  • Łatwe przypisania klawiszy – z odpowiednim configiem, poczujesz się jak w domu z Vim lub Screen
  • Wbudowane wiązania Vim-ish i Emacs-ish
  • Dobre zarządzanie układem, dużo jak w kafelkowym menedżerze okien
  • Unicode wydaje się po prostu działać z nowoczesnymi terminalami
  • Niektóre problemy z terminalami naprawione z TERM=tmux
  • Minusy
  • Slow – nie wiem dlaczego, ale naciśnięcia klawiszy wydają się laggy~ Nie ma więcej problemów z powolnością
  • Multiplexing wymusza całą szerokość i wysokość sesji do najmniejszego dołączonego terminala
  • Zawiesił się wiele razy na Mac OS X, tracąc całą sesję
  • Zawiódł na Linuksie po aktualizacji, gdzie nie mogłem ponownie połączyć się z moją starą sesją
  • Czasami brakuje naciśnięć klawiszy poleceń - ^A ^[ wymaga kilku prób dla trybu kopiowania
  • Nie można przenieść okna z jednego okna do drugiego Naprawione poleceniem join-pane
  • Brak rozwijania linii (lub “reflow” lub “rewrap”) po zmianie szerokości terminala (zmiana rozmiaru okna)

GNU Screen

  • Zalety
  • Niezwykle stabilny (v1. 0.0 był w 1987)
  • Niektóre problemy z terminalami poprawione z TERM=screen
  • Wbudowane wiązania w stylu Emacsa
  • Łatwe do przesuwania i kontrolowania poziomych paneli
  • Podczas multipleksowania, każdy dołączony terminal może zmienić rozmiar panelu
  • Wady
  • Brak pionowych podziałów bez poprawki (z wyjątkiem Ubuntu)
  • Podziały paneli są tracone przy odłączaniu
  • Uzyskanie Unicode do pracy wymaga trochę finezji i determinacji
  • Szalona konfiguracja linii statusu
15
15
15
2015-04-10 18:05:27 +0000

Zaletą ekranu jest to, że jest on dostępny niemalże od ręki w systemach Linux i Solaris. Kiedy musisz przełączać się tam i z powrotem pomiędzy platformami, miło jest nie mieć mentalnego przełączania kontekstu.

Jestem pewien, że możesz uzyskać tmux skompilowany na każdą platformę, ale czasami masz wystarczający dostęp, aby wykorzystać screen, ale faktyczni administratorzy systemu nie chcą dodawać żadnego oprogramowania, które nie jest absolutnie konieczne.

13
13
13
2012-04-19 17:30:12 +0000

Używam tmux od około 2 dni, więc mój niepohamowany entuzjazm dla niego nie został jeszcze złagodzony przez trafienie na irytujące przypadki użycia.

Podczas przechodzenia przez zwykłe bóle związane z przechodzeniem z jednego programu na drugi, uderzyło mnie kilka pozytywnych cech, ale cechą, która sprawiła, że wierzę, że nigdy nie wrócę do ekranu, jest użyteczność trybu kopiuj-wklej.

W screen nie można wejść w tryb kopiowania, przewinąć do tyłu bufora, a następnie przejść do innego okna.

W tmux, możesz mieć wiele okien jednocześnie w trybie kopiowania z buforem przewijanym do tyłu do różnych pozycji. Ponadto, istnieje wiele buforów kopiowania. I nie musisz łatać źródła, aby uzyskać ruch kursora fFtT.

8
8
8
2011-01-06 15:38:55 +0000

Rzeczy, które uzyskuję z tmuxa, a których nie mogę łatwo uzyskać na ekranie, to:

  1. robienie pionowych podziałów szyby
  2. multipleksowanie, którego używamy do zdalnego i lokalnego parowania.
8
8
8
2016-01-17 16:10:36 +0000

Zastąpiłem GNU Screen przez tmux w każdym przypadku użycia z wyjątkiem jednego - kiedy potrzebuję odpowiednika HyperTerminal do połączenia z portami szeregowymi. Jak zauważył Aaron Toponce w swoim artykule “Connecting To Serial Null Modems With GNU Screen” , tmux FAQ stwierdza:

screen ma wbudowaną obsługę serial i telnet; jest to nadęcie i jest mało prawdopodobne, aby zostało dodane do tmuxa.

Mój typowy przypadek użycia tmux to tworzenie wieloekranowych i wielookienkowych sesji rozwojowych w połączeniu z tmuxinator . Jeżeli chcesz się nauczyć tmux , polecam książkę Briana P. Hogana, tmux: Productive Mouse-Free Development .

4
4
4
2017-12-15 22:15:08 +0000

Jeden z opiekunów tmuxa, Thomas Adam, jest również wymieniony jako opiekun projektu screen, chociaż dotyka on tylko kodu tmuxa. Jest to ogromna przewaga tmuxa nad screenem.

3
3
3
2019-01-16 06:25:48 +0000

Od dłuższego czasu intensywnie korzystam z Screen'a, ale używam wersji, którą zmodyfikowałem w 2002 roku. Głównie dlatego, że chciałem, aby nawigacja po oknach “next/prev” była zgodna z kolejnością tworzenia nowych okien, podobnie jak w przypadku kafelkowego menedżera okien, takiego jak i3 lub Ion . Standardowe zachowanie ekranu to ‘next’ i ‘prev’ według numeru okna, więc zazwyczaj ‘nowe’ okno (chwytające najmniejszy dostępny numer) będzie znajdowało się gdzie indziej niż ‘następne’ okno - mylące, jeśli nie pamiętasz numerów. Moje preferowane zachowanie zostało od tego czasu zaimplementowane w Tmuxie jako flaga do polecenia new-window w 2010 , i opcja renumber-windows w 2012 . Moja poprawka do Screen, którą starałem się uczynić tak akceptowalną, jak to tylko możliwe, włączając w to dodatki do dokumentacji i tak dalej, nie wywołała żadnej dyskusji na liście Screen w lipcu 2002 (wtedy “screen@informatik.uni-erlangen.de”, nie mogę znaleźć archiwów). W rzeczywistości nie został on nawet uznany, nawet gdy wysłałem go ponownie rok później.

Od 2002 roku, “przeformatowałem” moją łatę kilka razy, aby zastosować ją do nowszych wersji Screena. Jednakże, gdy doszedłem do wersji 4.3 (2015) zauważyłem nieudokumentowaną zmianę, która zepsuła jeden z moich sposobów użycia Screena - mianowicie, że ‘stuff’ teraz interpoluje zmienne środowiskowe . Nie potrzebowałem tej funkcji i nie mogłem wymyślić, jak łatwo uciec od argumentu do ‘stuff’ (tak, że mógłbym wysłać tekst zawierający znaki dolara), więc po prostu nadal używałem wersji 4.0 (z 2004 roku).

Używam ‘stuff’ Screen'a (‘send-keys’ w Tmux) w funkcji Emacsa, która wysyła zawartość bieżącego regionu Emacsa do określonego numeru okna. W ten sposób, gdy piszę kod w języku skryptowym, otwieram interpreter, nadaję oknu intepretera specjalny numer, a następnie mogę wysyłać linie kodu z mojego okna edytora bezpośrednio do okna interpretera używając tego wiązania Emacsa. Jest to hacky, ale podoba mi się bardziej niż czysto-Emacsowe rozwiązanie , ponieważ mogę również współdziałać z interpreterem w jego oknie Screen, używając standardowych naciśnięć klawiszy. To jest trochę jak GUI IDE, ale nie muszę używać myszy lub wpatrywać się w migający kursor.

Kolejną funkcją, którą zaimplementowałem w mojej łatce jest możliwość “zaznaczenia” okna, a następnie zmiany położenia zaznaczonego okna tak, aby było “następne” po bieżącym. Dla mnie jest to znacznie bardziej naturalny sposób zmiany kolejności okien niż zmiana numeracji; przypomina to paradygmat kopiuj/wklej lub “przeciągnij i upuść”. (Ostatnio odkryłem jak to robić w i3 ](https://www.freelists.org/post/i3-discuss/is-there-a-way-to-select-a-window-for-repositioning,1) również.)

Powinno być możliwe zrobienie tego samego w Tmuxie, na przykład od 2015 istnieje możliwość “zaznaczania” okien. A może bardziej elementarne rozwiązanie można opracować za pomocą skryptów stateful shell. Zaimplementowałem krótki skrypt i przypisania klawiszy, aby wypróbować metodę “zaznaczonego okna” i zadziałało to kilka razy, ale potem Tmux zawiesił się z “[utracony serwer]”. Potem odkryłem, że Tmux zawiesza się nawet bez mojej próby zrobienia czegokolwiek skomplikowanego. Najwyraźniej u niektórych użytkowników zawiesza się od kilku lat co najmniej . Czasami serwer się zawiesza, czasami zaczyna wykorzystywać 100% CPU i przestaje reagować. Nigdy nie widziałem, żeby Screen zrobił którąś z tych rzeczy.

W teorii, Tmux jest lepszy od Screena pod kilkoma względami. Ma znacznie lepszą skryptowalność, co oznacza, że możesz robić rzeczy takie jak zapytanie o listę okien w bieżącej sesji z linii poleceń, co jest niemożliwe w przypadku Screena. Na przykład w 2015 roku Screen dodał polecenie “sortowania okien według tytułu” . Nie jestem pewien, kiedy takie wyspecjalizowane polecenie byłoby przydatne, ale to i bardziej praktyczne wariacje (np. sortuj okna według użycia procesora) można by stosunkowo łatwo zrobić ze skryptu powłoki w Tmuxie. Wydaje mi się, że trudno byłoby zrobić coś tak kreatywnego w Screenie, przynajmniej bez modyfikowania kodu C.

Jak wspomnieli inni plakaty, Tmux ma model pojedynczego serwera, który uważam za główną wadę, szczególnie gdy serwer się zawiesza. Możliwe jest obejście tego problemu poprzez określenie osobnego gniazda dla każdej “sesji”. Mimo to wolę domyślny model Screen'a jeden serwer na sesję, który wydaje się nieco bardziej elegancki.

Praca z kodem Screena, jeszcze w 2002 roku, była dla mnie edukacyjna i przyjemna. Co dziwne, przy wszystkich swoich dodatkowych funkcjach, Tmux ma około 25% mniej linii kodu niż Screen (30k vs 40k). Zauważyłem, że Tmux używa wielu struktur danych typu drzewo i lista, które były dla mnie nieco trudne do zrozumienia. Screen wydawał się preferować tablice.

Jak rozumiem, ponieważ interfejs terminala Unix jest tak stabilny, istnieje niewielka potrzeba, aby kod Screen lub Tmux dostosowywał się do zmian w bazowym systemie operacyjnym. Programy te tak naprawdę nie mają aktualizacji bezpieczeństwa, jak przeglądarki internetowe, serwery internetowe czy nawet powłoka. Nie zauważyłem żadnych problemów z uruchomieniem mojej niestandardowej wersji Screen, ostatnio uaktualnionej w 2004 roku (z wyjątkiem konieczności dodania kilku plików konfiguracyjnych, by zapobiec usuwaniu przez Systemd gniazda ; te pliki i tak są zazwyczaj częścią pakietu dystrybucyjnego). Być może mógłbym po prostu obejść problemy, które napotkałem w Tmuxie poprzez uruchomienie wersji Tmuxa sprzed jego awarii. Oczywiście, jeśli wystarczająco dużo użytkowników tak zrobi, nie będzie to zbyt dobre dla nowych użytkowników, ponieważ oznacza to, że mniej ekspertów będzie szukało błędów w najnowszych oficjalnych wersjach tych programów. Jednak trudno jest mi się zmotywować do przejścia na produkt, który jest dla mnie niestabilny (najnowszy Tmux) lub któremu brakuje pewnych funkcji, na których mi zależy (standardowy Screen).

Wiem, że nie jest to łatwa odpowiedź na pytanie OP, ale mam nadzieję, że mój punkt widzenia był przydatny.

2
2
2
2012-06-21 15:27:36 +0000

Powiedziałbym, że dostępność ekranu jest jego mocną stroną, ale jego system okienkowy nie jest tak łatwy w obsłudze jak tmux . Muszę powiedzieć, że obecnie używam gnu-screen przez większość czasu i w rezultacie mam mnóstwo zakładek terminala zamiast okien Screen.

@Jed Schneider: Możesz uzyskać pionowe podziały okien za pomocąCtrl+A, a następnie | (pionowy pasek).