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.