Я собираюсь вернуться к использованию GNU Screen, но я слышал, как люди иногда упоминают tmux как лучшую альтернативу. Действительно ли он предлагает альтернативу всем функциям экрана, таким как мониторинг активности в разных окнах и т.д.? Каковы плюсы и минусы каждого?
233
9 ответов
154
Некоторые из (основных) причин, по которым я предпочитаю tmux над screen:
- Строка состояния намного проще в использовании. Вы можете легко настроить различные тексты / стили для текущего окна, окон с активностью и т.д., А также можете размещать элементы слева и справа от строки состояния, включая команды оболочки, которые можно запускать с заданным интервалом (по умолчанию 15 с).
- Почти любая команда, которую вы можете запустить внутри
tmuxможет быть запущена из оболочки с помощьюtmux command [args]. Это делает его очень простым в написании сценариев, а также облегчает выполнение сложных команд. - Гораздо точнее автоматическое переименование окон. Хотя
screenустанавливает заголовок на основе первого слова команды и требует настройки оболочки, чтобы сделать это даже в окне оболочки,tmuxотслеживает, какие процессы на самом деле выполняются в каждом окне, и соответствующим образом обновляет заголовок. Таким образом, вы получите динамическое переименование с любой оболочкой и нулевой конфигурацией. Например: допустим, вы работаете с Z Shell; имя окна будет "zsh". Теперь предположим, что вы хотите отредактировать некоторый файл конфигурации, поэтому выsudo emacs /etc/somefile. Пока sudo запрашивает ваш пароль, имя окна будет "sudo", но как только вы это сделаете иsudoзапуститemacs, заголовок будет "emacs". Когда вы все закончите и выйдете изemacs, заголовок снова изменится на "zsh". Это очень полезно для отслеживания окон, а также может быть особенно полезно в определенных ситуациях, например, если у вас есть какой-то длительный процесс в другом окне, который иногда запрашивает ввод с помощьюdialog; имя окна изменится на "диалог", когда это произойдет, так что вы будете знать, что вам нужно переключиться на это окно и что-то сделать. - Более приятная обработка сессии (ИМХО). Вы можете сделать намного больше с сессиями внутри самого
tmux. Вы можете легко переключаться, переименовывать и т.д., И вы можете перемещать и обмениваться окнами между сеансами. Он также имеет другую модель, где у каждого пользователя есть сервер, который контролирует его / ее сеансы и к которому клиент подключается. Недостатком этого является то, что в случае сбоя сервера вы потеряете все; У меня никогда не было сбоев сервера. tmuxпохоже, более активно развивается. Обновления происходят довольно часто, и вы можете подать отчет об ошибке или запрос функции в соответствии с этим FAQ и получить ответ в течение нескольких дней.
Это только основные вещи, которые сразу приходят на ум. Есть и другие мелочи, и я уверен, что забыл кое-что. Хотя, безусловно, стоит попробовать tmux .
87
(Сеансы - это коллекции окон, которые можно отсоединить и подключить позже. Окна могут содержать одну или несколько панелей. Например, конфиги, проверьте здесь и здесь.)
tmux
- Pros
- Может отправлять ключи на другие панели, вроде IDE
- Простые сочетания клавиш - с правильной конфигурацией вы будете чувствовать себя как дома с Vim или Screen
- Встроенные привязки Vim-ish и Emacs-ish
- Хорошее управление компоновкой, очень похоже на менеджер окон
- Unicode, похоже, просто работает с современными терминалами
- Некоторые проблемы с терминалом исправлены с помощью
TERM=tmux
- Cons
Медленно - не знаю, почему, но нажатия клавиш кажутся медленными- Мультиплексирование приводит всю ширину и высоту сеанса к наименьшему присоединенному терминалу.
- Несколько раз падал в Mac OS X, теряя весь сеанс
- Сбой в Linux после обновления, когда я не смог подключиться к своей старой сессии
- Иногда пропускает комбинации клавиш - ^ A ^ [ делает несколько попыток в режиме копирования
Невозможно переместить панель из одного окна в другое.Исправлено с помощью командыjoin-pane- Никакая развертка линии (или "перекомпоновка" или "перемотка") после изменения ширины терминала (изменение размера окна)
Экран GNU
- Pros
- Чрезвычайно стабильный (v1.0 был в 1987 году)
- Некоторые проблемы с терминалом устранены с помощью
TERM=screen - Встроенные привязки Emacs-ish
- Легко перемещать и контролировать горизонтальные панели
- При мультиплексировании любой подключенный терминал может изменить размер панели
- Cons
- Нет вертикальных расколов без патча (кроме Ubuntu)
- Расколы панели теряются при отсоединении
- Чтобы заставить работать Unicode, нужно немного ловкости и решимости
- Сумасшедшая конфигурация строки состояния
10
Профи для экрана: он доступен в значительной степени из коробки на Linux и Solaris. Когда вам приходится переключаться между платформами назад и вперед, хорошо бы не переключать ментальный контекст.
Я уверен, что вы можете скомпилировать tmux на любой платформе, но иногда у вас достаточно доступа для использования экрана, но реальные системные администраторы не хотят добавлять программное обеспечение, которое не является абсолютно необходимым.
8
Вещи, которые я получаю из tmux, я не могу легко увидеть на экране:
- сделать вертикальное разделение панели
- мультиплексирование, которое мы используем для удаленного и локального сопряжения.
8
Я использую tmux уже около 2 дней, так что мой безудержный энтузиазм по поводу этого еще не умерился от попадания надоедливых вариантов использования. Пройдя через обычные растущие проблемы перехода от одной программы к другой, я был поражен несколькими положительными особенностями, но функция, которая заставляет меня верить, что я никогда не вернусь к экрану, - это утилита режима копирования-вставки. На экране вы не можете войти в режим копирования, прокрутить обратно в буфер, а затем перейти в другое окно. В tmux у вас может быть несколько окон одновременно в режиме копирования с прокруткой буфера обратно в разные позиции. Также есть несколько буферов копирования. И вам не нужно исправлять источник, чтобы получить движение курсора FFTT.
5
Я заменял GNU Screen на tmux во всех случаях использования, кроме одного - когда мне нужен эквивалент HyperTerminal для подключения к последовательным портам. Как отметил Аарон Топонсе в своей статье «Подключение к последовательным нуль-модемам с экраном GNU», часто задаваемые вопросы по tmux гласят :
экран имеет встроенный последовательный порт и поддержку telnet; это раздувание и вряд ли будет добавлено в tmux.
Мой типичный пример использования tmux - создание многопанельных и многооконных сеансов разработки в сочетании с tmuxinator. Если вы хотите изучать tmux, я рекомендую приобрести книгу Брайана П. Хогана, tmux: Продуктивная разработка без мышки.
1
Я бы сказал, что доступность экрана - это его сила, но его оконная система не так проста в управлении, как у tmux . Должен сказать, что в настоящее время я использую gnu-screen большую часть времени, и в результате вместо окон экрана появляется множество вкладок терминала.
@Jed Schneider: Вы можете получить вертикальное разделение панели с помощью Ctrl+A, а затем | (вертикальная черта).
1
Один из сопровождающих tmux, Томас Адам, также указан в качестве сопровождающего для screen проекта, хотя он касается только кода tmux. Это огромный профессионал Tmux над экраном.
0
Я долгое время активно пользовался 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) или в котором отсутствуют определенные функции, которые мне нужны (стандартный экран).
Я знаю, что это не дает простого ответа на вопрос ОП, но я надеюсь, что моя точка зрения была полезной.