Я долгое время активно пользовался Screen, но я использую версию, которую я изменил еще в 2002 году. Главным образом потому, что я хотел, чтобы окно навигации «следующий / предыдущий» соответствовало порядку, в котором новый были созданы окна, похожие на оконный менеджер листов, такой как i3 или Ion . Стандартное поведение экрана заключается в том, что «next» и «prev» идут по номеру окна, поэтому обычно «новое» окно (захватывая наименьшее доступное число) будет располагаться в другом месте, чем «следующее» окно - сбивая с толку, если вы не не помню цифры. С тех пор мое предпочтительное поведение было реализовано в Tmux как флаг для команды new-window в 2010 году , а опция renumber-windows - в 2012 году., Мой патч Screen, который я пытался сделать как можно более приемлемым, включая добавление документации и т. Д., Не вызвал никаких обсуждений в списке Screen в июле 2002 года (тогда «screen@informatik.uni-erlangen.de» не может найти архивы). На самом деле это даже не было признано, даже когда я отправил его через год.
С 2002 года я несколько раз «перебирал» свой патч, чтобы применить его к более новым версиям Screen. Однако, когда я добрался до версии 4.3 (2015), я заметил недокументированное изменение, которое нарушило одно из моих применений экрана - а именно, что «вещи» теперь интерполируют переменные среды . Мне не нужна была эта функция, и я не мог понять, как легко избежать аргумента для «вещи» (чтобы я мог отправлять текст, содержащий знаки доллара), поэтому я просто продолжал использовать версию 4.0 (с 2004 года).
Я использую Screen 'stuff' ('send-keys' в Tmux) в функции Emacs, которая отправляет содержимое текущей области Emacs на определенный номер окна. Таким образом, когда я пишу код на языке сценариев, я открываю интерпретатор, присваиваю окну интерпретатора специальный номер, а затем могу отправлять строки кода из окна редактора непосредственно в окно интерпретатора, используя эту привязку Emacs. Это хакерство, но мне оно нравится больше, чем в чистом Emacs-решении , поскольку я также могу взаимодействовать с интерпретатором в его окне Screen с помощью стандартных нажатий клавиш. Это немного похоже на GUI IDE, но мне не нужно использовать мышь или смотреть на мигающий курсор.
Еще одна функция, которую я реализовал в своем патче, - это возможность «пометить» окно, а затем изменить положение помеченного окна, чтобы оно было «следующим» после текущего. Для меня это гораздо более естественный способ переупорядочения окон, чем перенумерация; это похоже на парадигму копирования / вставки или «перетаскивание». ( Недавно я понял, как это сделать в i3 .)
В Tmux должно быть возможно сделать то же самое, например, с 2015 года есть возможность «пометить» панель. Или, может быть, более простое решение может быть разработано с помощью сценариев оболочки с сохранением состояния. Я реализовал короткий скрипт и привязку клавиш, чтобы попробовать метод «отмеченная панель», и он работал несколько раз, но затем Tmux потерпел крах с «[потерянный сервер]». Потом я обнаружил, что Tmux рушится, даже не пытаясь сделать что-то сложное. Видимо , это был сбой для некоторых пользователей на несколько лет , по крайней мере . Иногда происходит сбой сервера, иногда он начинает использовать 100% ЦП и перестает отвечать на запросы. Я никогда не видел, чтобы Screen делал что-либо из этого.
Теоретически, Tmux превосходит Screen по нескольким причинам. У него гораздо лучшая возможность написания сценариев, что означает, что вы можете делать такие вещи, как запрос списка окон в текущем сеансе из командной строки, что невозможно с Screen. Например, в 2015 году на экран добавлена команда «Сортировать окна по заголовку» . Я не уверен, когда такая специализированная команда будет полезна, но этот и более практичные варианты (например, сортировка окон по загрузке процессора) можно относительно легко сделать из сценария оболочки в Tmux. Мне было бы трудно сделать что-то настолько креативное в Screen, по крайней мере, без изменения кода на Си.
Как упоминалось в других постерах, у Tmux есть модель с одним сервером, которую я вижу в качестве основного недостатка, особенно при сбое сервера. Это можно обойти, указав отдельный сокет для каждой «сессии». Тем не менее я предпочитаю Screen по умолчанию один сервер на сеанс, который кажется немного более элегантным.
Работа с кодом Screen в 2002 году была для меня познавательной и приятной. Как ни странно, для всех своих дополнительных функций Tmux имеет примерно на 25% меньше строк кода, чем Screen (30k против 40k). Я заметил, что Tmux использует много древовидных и списочных структур данных, которые мне было немного трудно понять. Экран, казалось, предпочел массивы.
Насколько я понимаю, поскольку интерфейс терминала Unix настолько стабилен, нет необходимости адаптировать код Screen или Tmux к изменениям в базовой операционной системе. Эти программы на самом деле не имеют обновлений безопасности, таких как веб-браузеры или веб-серверы или даже оболочка. Я не заметил проблем с запуском моей пользовательской версии Screen, последнее обновление которой было в 2004 году (за исключением необходимости добавления некоторых файлов конфигурации, чтобы предотвратить удаление сокета Systemd; в любом случае эти файлы обычно являются частью дистрибутива). Возможно, я мог бы просто обойти проблемы, с которыми я столкнулся в Tmux, запустив версию Tmux до того, как она начала падать. Конечно, если достаточное количество пользователей сделает это, это будет не очень хорошо для новых пользователей, поскольку это означает, что меньшее количество экспертов будет искать ошибки в последних официальных версиях этих программ. Однако трудно мотивировать себя перейти на продукт, который нестабилен для меня (последний Tmux) или в котором отсутствуют определенные функции, которые мне нужны (стандартный экран).
Я знаю, что это не дает простого ответа на вопрос ОП, но я надеюсь, что моя точка зрения была полезной.