Re: tmux на локальной машине
>>>>> Sergey Matveev <stargrave@stargrave.org> writes:
>>>>> *** Ivan Shmakov <ivan@siamics.net> [2017-07-16 11:49]:
>> Команды перемещения у Screen, разумеется, тоже есть; Less-like, если
>> угодно; % — в начало буфера; G — в конец; etc.
>> Мне не приходилось участвовать в разработке GNU Screen, но не вижу
>> причин считать, что предложения «добавить Vi-клавиш» будут заведомо
>> отвергнуты разработчиками. Разве что из соображений «обратной
>> совместимости».
> Повторюсь: тут вопрос субъективный похоже. Я не вижу смысла (для
> себя) что-то добавлять или как-то улучшать GNU screen когда есть
> Tmux.
Не исключено, что кто-то из читающих рассылку заинтересуется.
Вопрос подписчиков был ведь в том, чтобы сравнить Screen и Tmux?
Вот мы этим и занимаемся, не так ли? Сам я, единолично,
сравнить их не могу, коль скоро имею опыт использования лишь
одного, и ознакомление с другим не является для меня, на текущий
момент, приоритетной задачей.
> Как минимум я наслышан о качестве кода последнего, но не о качестве
> первого.
Вполне возможно. AIUI, GNU Screen в этом году празднует свое
тридцатилетие. За такой срок в коде имеют свойство
накапливаться «особенности.» Если этому активно не
противодействовать, во всяком случае.
> Ища информация по поводу screen vs tmux, постоянно натыкался на то
> что в tmux-е раньше стало всё хорошо с Unicode-ом, итд, итд.
А вот это слегка сомнительно. Tmux появился в 2007 г., и на тот
момент, IIRC, GNU Screen у меня с UTF-8 работал вполне
адекватно.
Впрочем, те же символы двойной ширины мне были без особой
надобности, так что…
[…]
> Насколько понимаю, если запустить screen mutt, то после выхода из
> mutt-а и screen завершит свою работу?
Если запустить Screen и в нем создать ($ screen mutt) окно с
Mutt, то по завершению Mutt окно действительно будет закрыто.
Или станет «зомби» — в зависимости от настроек.
> Очень часто проще выйти из mutt чтобы например зайти в default
> почтовый ящик. Поэтому тут нужно именно shell запустить, а в нём как
> бы вызвать mutt команду, чтобы при выходе из неё я снова попал в
> shell.
Э, нет, мне проще запустить два Mutt — каждый в своем окне.
$ ps -o pid,lstart,cmd -C mutt
PID STARTED CMD
12148 Wed Jul 5 04:40:13 2017 mutt XXX
15184 Sun Jul 2 12:26:51 2017 mutt YYY
[…]
>> Никакой «имитации интерактивности» — исключительно «штатные»
>> интерфейсы.
>> В общем случае, это кажется куда как более надежным. Мало ли о чем
>> запущенное приложение захочет спросить пользователя сразу после
>> запуска? SSH-клиент, например, может предупреждение о возможном
>> MitM выдать — и попросить подтвердить доступ. Или, в отсутствие
>> ключа у агента — пароль спросить.
> Вот именно под этим я и подразумевал что tmux удобнее (субъективно).
На самом деле, здесь нет различия между Screen и Tmux: первый
также имеет команду (stuff) для имитации ввода в окно. E. g.:
### my.screen
## Usage: $ screen -X source my.screen
screen -t mutt 27
stuff mutt\n
### my.screen ends here
Другое дело, что я этой возможностью пользуюсь крайне редко
(если вообще пользуюсь), и если у Screen есть дефекты в ее
реализации — я с ними не сталкивался.
> Отчасти я согласен что это *потенциально* менее безопаснее — но я
> считаю что нечего запускать ПО которому не доверяете, от которого
> ждёте такого подвоха.
Причем здесь доверие? Я уже привел один пример: $ ssh REMOTE
может дать доступ к Shell на удаленной машине; а может —
предупреждение о том, что ключ REMOTE не соответствует
сохраненному в ~/.ssh/known_hosts. Ни stuff, ни set-buffer +
paste-buffer адекватно эту ситуацию обработать, IIUC, не
позволяют.
Еще одна возможная ситуация — «внезапное» изменение умолчаний.
Так, традиционно, Home и End в Emacs перемещали точку в начало и
конец буфера, соответственно. Затем разработчики решили «быть
как все» и с выходом 21.1 в 2001 г. эти клавиши были по
умолчанию переназначены на перемещение в начало и конец /строки./
При непосредственном взаимодействии с программой я могу
надеяться уследить за отличной от ожидаемой реакцией и либо
начать выяснять причины, либо «подстроиться».
Из кода? Я определенно предпочту более стабильные «командные»
интерфейсы. Вроде $ emacs --eval='(beginning-of-buffer)', или
$ bash --rcfile=XXX.
> И когда речь заходит о «человеческом» удобстве, то тут не всегда до
> безопасности. Я хочу *именно*, как вы выразились, имитации
> интерактивности — я хочу буквально заменить себя, причём меньшей
> болью. Я согласен что многое можно заменить shell-скриптами, то если
> я вот каждый раз когда занимаюсь проектом XXX делаю:
> cd ~/work/xxx
> venv
> workon xxx
> cat todo.txt
> export PS="..."
> то исключительно удобно вот как всё написано — взять и обернуть в
> tmux команды, без создания shell-скрипта который правильно включит
> virtualenv-ы, выставит переменные окружения, итд.
Секунду. Разве «обернуть в tmux команды» не означает «создать
shell-скрипт» (с командами tmux)?
А если так, то в чем преимущество set-buffer + paste-buffer
перед, например, $ bash --rcfile=? (Предполагая, что
используется именно Bash. Думаю, иные реализации Shell
предоставляют схожие возможности.)
Я так подозреваю, не только мне сие любопытно.
[…]
>>> На самом деле кроме «su -» ещё и его пароль вставляется
>>> (загруженный с зашифрованного диска — мол если диск подключен, то
>>> это уж точно авторизованный пользователь).
>> … Любопытно, а умеет ли sudo(8) учитывать факт наличия произвольных
>> файлов при выполнении авторизации?
> Хочу заметить что пароль вставляется «имитацией интерактивности» —
> то есть tmux туда пихает сам пароль, прочитанный из файла, дальше
> лупит enter.
/Цель/ работы данного кода, как я ее понял, — дать пользователю
root-доступ, если «подключен зашифрованный диск».
Я не вижу причины, по которой некий «шлюз привилегий» не может
проверить факт /наличия/ файла — и дать root-доступ без
необходимости ввода какого-либо пароля. (Или хранения оного.)
--
FSF associate member #7257 np. Bittersweet — Apocalyptica 3013 B6A0 230E 334A
Reply to: