Я собираюсь вернуться к использованию GNU Screen , но я слышал, как люди время от времени упоминали tmux как лучшую альтернативу. Действительно ли она предлагает альтернативу всем функциям Screen , таким как мониторинг активности в разных окнах и т.д.? Каковы преимущества и недостатки каждой из них?
Некоторые из (основных) причин, по которым я предпочитаю tmux, а не screen:
tmux, может быть запущена из оболочки с tmux command [args]. Это делает ее очень легкой для скриптов, а также облегчает выполнение сложных команд. screen устанавливает заголовок на основе первого слова команды и требует настройки оболочки для выполнения даже этого в окне оболочки, tmux отслеживает, какие процессы на самом деле выполняются в каждом окне, и обновляет заголовок соответствующим образом. Таким образом, вы получаете динамическое переименование с любой оболочкой и нулевой конфигурацией. Например: Допустим, вы запускаете Z оболочку; имя окна будет “zsh”. Теперь, допустим, вы хотите отредактировать какой-нибудь конфигурационный файл, поэтому набираете sudo emacs /etc/somefile. Пока sudo запрашивает ваш пароль, имя окна будет “sudo”, но как только вы это сделаете и sudo запустит emacs, заголовок будет “emacs”. Когда вы все закончите и выйдете из emacs, заголовок изменится обратно на “zsh”. Это довольно полезно для отслеживания окон, а также может быть особенно полезно в конкретных ситуациях, например, если у вас есть какой-то длительный процесс в другом окне, который иногда подсказывает вам вводить данные с помощью dialog; при этом название окна изменится на “dialog”, так что вы будете знать, что вам нужно переключиться на это окно и что-то сделать. tmux. Вы можете легко переключаться, переименовывать и т.д., и вы можете перемещать и совместно использовать окна между сессиями. Она также имеет другую модель, где каждый пользователь имеет сервер, который контролирует его / ее сессии, и к которому клиент подключается. Недостатком является то, что если сервер выходит из строя, вы теряете все; однако, у меня никогда не было сбоя сервера. tmux, кажется, более активно развивается. Обновления происходят довольно часто, и вы можете подать сообщение об ошибке или запрос на функцию согласно этому FAQ и получить ответ в течение нескольких дней. Это только основные вещи, которые сразу приходят на ум. Есть и другие мелочи, и я уверен, что забываю некоторые вещи. Хотя, определенно стоит попробовать tmux.
(Sessions - это наборы windows, которые можно отсоединить и прикрепить позже. Windows может содержать одну или более panes. Например, конфигурационные файлы, смотрите здесь и здесь ).
TERM=tmux join-pane TERM=screen Профессионал для экрана: он доступен практически из коробки под Linux и Solaris. Когда вам приходится переключаться между платформами, приятно не иметь переключателя мысленного контекста.
Я уверен, что вы можете скомпилировать tmux на любой платформе, но иногда у вас достаточно простого доступа для использования экрана, но на самом деле системные администраторы не хотят добавлять программное обеспечение, которое не является абсолютно необходимым.
Я использую tmux уже около 2 дней, так что мой безудержный энтузиазм к нему еще не сдержан ударами по раздражающим случаям использования.
Проходя через привычные нарастающие боли при переходе с одной программы на другую, я был поражен несколькими положительными особенностями, но функция, которая заставляет меня поверить, что я никогда не вернусь к экрану, - это утилита режима копирования-вставки.
В screen нельзя войти в режим копирования, прокрутить обратно в буфер, а затем перейти в другое окно.
В tmux вы можете иметь несколько окон одновременно в режиме копирования, при этом буфер прокручивается обратно в разные положения. Также есть несколько буферов копирования. И вам не нужно исправлять источник, чтобы получить движение курсора fFtT.
То, что я получаю из tmux, мне нелегко попасть на экран:
Я заменил GNU Screen на tmux во всех случаях использования, кроме одного, когда мне нужен HyperTerminal эквивалент для подключения к последовательным портам. Как заметил Аарон Топонс в своей статье “Подключение к последовательным нуль-модемам с помощью GNU-экрана” , в tmux FAQ говорится: Экран
имеет встроенную поддержку последовательного порта и telnet; он раздувается и вряд ли будет добавлен в tmux.
Мой типичный случай использования tmux заключается в создании многопанельных и многооконных сеансов разработки в сочетании с tmuxinator . Если вы хотите изучить tmux , я рекомендую взять книгу Брайана П. Хогана, tmux: Productive Mouse-Free Development .
Один из мейнтейнеров tmux, Томас Адам, также включен в список ](https://savannah.gnu.org/project/memberlist.php?group=screen) в качестве мейнтейнера проекта screen, хотя он касается только кода tmux. Это огромный профессионал tmux на экране.
Я долгое время был тяжелым пользователем Screen, но я использую версию, которую я модифицировал еще в 2002 году. В основном потому, что я хотел, чтобы порядок расположения окон “next/prev” навигации совпадал с порядком создания новых окон, подобно оконному менеджеру вроде i3 или Ion . Стандартное поведение Screen'а заключается в том, что ‘следующее’ и ‘prev’ будут идти по номеру окна, так что обычно ‘новое’ окно (схватив наименьший доступный номер) будет расположено где-то в другом месте, чем ‘следующее’ окно - путаница, если вы не помните номера. С тех пор мое предпочитаемое поведение было реализовано в Tmux в виде флага для команды new-window в 2010 , и опции renumber-windows в 2012 . Мой патч Screen, который я пытался сделать максимально приемлемым, включая дополнения к документации и т.д., не вызвал никаких обсуждений в списке Screen в июле 2002 года (тогда “screen@informatik.uni-erlangen.de”, не может найти архивы). На самом деле это даже не было признано, даже когда я отправил его снова через год.
С 2002 года я “переделал” патч пару раз, чтобы применить его к более новым версиям Screen. Однако, когда я добрался до версии 4.3 (2015), я заметил недокументированное изменение, которое сломало одно из моих применений экрана - а именно то, что ‘stuff’ теперь интерполирует переменные окружения . Мне не нужна была эта возможность, и я не мог понять, как легко избежать аргументации в ‘stuff’ (чтобы я мог посылать текст, содержащий знаки доллара), так что я просто продолжал использовать версию 4.0 (с 2004).
я использую ‘stuff’ (‘send-клавиши’ в Tmux) в функции Emacs, которая посылает содержимое текущего региона Emacs на определенный номер окна. Таким образом, когда я пишу код на скриптовом языке, я открываю интерпретатор, даю целому окну специальный номер, а затем я могу послать строки кода из окна редактора прямо в окно интерпретатора, используя эту привязку Emacs. Это сложно, но мне это нравится больше, чем чистое решение от Emacs , так как я также могу взаимодействовать с интерпретатором в его окне Screen, используя стандартные нажатия клавиш. Это немного похоже на GUI IDE, но мне не нужно использовать мышь или пялиться на мигающий курсор.
Еще одна возможность, которую я реализовал в своем патче - это возможность “пометить” окно, а затем перепозиционировать помеченное окно, чтобы оно было “следующим” после текущего. Для меня это гораздо более естественный способ переупорядочивания окон, чем перенумерация; это как парадигма копирования/вставки, или “перетаскивание”. (Я недавно понял, как это сделать в i3 тоже.)
В Tmux должно быть возможно делать то же самое, например с 2015 есть возможность “разметки” панели. Или, возможно, более элементарное решение можно было бы разработать с помощью скриптов оболочки с контролем состояния. Я реализовал короткий скрипт и привязки клавиш, чтобы попробовать метод “маркировки панели”, и это сработало несколько раз, но затем в Tmux произошёл сбой с “[потерянным сервером]”. Потом я обнаружил, что Tmux рухнул, даже не пытаясь сделать ничего сложного. Очевидно, что он падал для некоторых пользователей в течение по крайней мере, нескольких лет . Иногда происходит сбой сервера, иногда он начинает использовать 100% центрального процессора и становится невосприимчивым. Я никогда не видел, чтобы Screen делал что-то подобное.
Теоретически Tmux превосходит Screen по нескольким параметрам. Он имеет гораздо лучшую скриптографируемость, то есть вы можете делать такие вещи, как запрос списка окон в текущей сессии из командной строки, что невозможно при использовании Screen. Например, в 2015 Screen добавлена команда “сортировать окна по заголовку” . Я не уверен, когда такая специализированная команда будет полезна, но это и более практичные варианты (например, сортировка окон по использованию процессора) относительно легко могут быть сделаны из скрипта оболочки в Tmux. Мне кажется, что в Screen было бы сложно сделать что-то настолько креативное, по крайней мере, без модификации кода на C.
Как упоминалось в других плакатах, в Tmux есть модель с одним сервером, который я вижу основным недостатком, особенно когда сервер ломается. Об этом можно поработать, указав отдельный сокет для каждой “сессии”. Тем не менее, я предпочитаю односерверную модель Screen по умолчанию, что кажется немного более элегантным.
Работа с кодом Screen, еще в 2002 году, была для меня познавательной и приятной. Как ни странно, но при всех своих дополнительных возможностях Tmux имеет примерно на 25% меньше строк кода, чем Screen (30k против 40k). Я заметил, что в Tmux используется много деревьев и списков структур данных, которые мне было немного сложно понять. Экран, казалось, предпочитает массивы.
Как я понимаю, потому что интерфейс Unix-терминала настолько стабилен, что код Screen или Tmux практически не нуждается в адаптации к изменениям в базовой операционной системе. Эти программы на самом деле не имеют обновлений безопасности, таких как веб-браузеры, веб-серверы или даже оболочка. Я не заметил никаких проблем при запуске моей пользовательской версии Screen, последней обновленной в 2004 году (за исключением необходимости добавления некоторых конфигурационных файлов, чтобы предотвратить удаление Systemd сокета ; эти файлы, как правило, все равно являются частью дистрибутива). Возможно, я смогу обойти проблемы, с которыми столкнулся в Tmux, запустив версию Tmux до того, как она начала давать сбой. Конечно, если достаточное количество пользователей сделает это, то это будет не очень хорошо для новых пользователей, так как это означает, что меньше экспертов будут искать ошибки в последних официальных версиях этих программ. Однако, трудно мотивировать себя на переход на продукт, который для меня нестабилен (последний Tmux) или который не имеет определенных возможностей, которые я хочу (стандартный Screen).
Я знаю, что это не дает простого ответа на вопрос ОП, но я надеюсь, что моя точка зрения была полезной.
Я бы сказал, что доступность экрана - это его сила, но его оконная система не так проста в обращении, как tmux ’s. Должен сказать, что большую часть времени в настоящее время я использую gnu-screen и в результате вместо окон Screen у меня есть множество терминальных вкладок.
@Jed Schneider: Вы можете получить вертикальные разделения панели с помощьюCtrl+A, а затем | (вертикальная панель).