>>>>> Sergey Matveev <stargr...@stargrave.org> writes: >>>>> *** Ivan Shmakov <i...@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