Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-17 Пенетрантность Artem Chuprina 
Tim Sattarov -> debian-russian@lists.debian.org  @ Mon, 17 Jul 2017 15:16:56 
-0400:

 > On 17/07/17 02:31 AM, Jurgen V. Uzbekoff wrote:
 >> Но ты спросил — я рассказываю про личный опыт. 
 > Понял, буду больше спрашивать :)
 >>> А разве в эмуляторе этого нет ? Зачем screen ?
 >> Может в каком-то эмуляторе это и есть. В моём текущем я не обнаружил (а до
 >> сегодняшнего дня даже и не пытался искать). И то, что я не пытался искать
 >> эту функцию не только в этом terminal-emulator, но и в других, в которых я
 >> запускал screen, мне очень нравится — мне в любом эмуляторе было
 >> достаточно привычного функционала screen.

 > у меня наверное проблема с быстрым переключением между сессиями: когда
 > вводить последовательность нажатий, для переключения между сессиями.
 > Против простого Alt-[1-9] в терминале

 > Кстати, посмотрел на tmux ещё раз - что мне нравится в нём, так это
 > статусная строка, не потеряешься, в screen иногда не понятно, в каком
 > уровень реальности я сейчас...

Мне казалось, что в screen ее тоже можно включить. Только она по
умолчанию выключена. Потому что дисплей на телефоне не резиновый... :)

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-17 Пенетрантность yuri . nefedov 

On Mon, 17 Jul 2017, Tim Sattarov wrote:


у меня наверное проблема с быстрым переключением между сессиями: когда
вводить последовательность нажатий, для переключения между сессиями.
Против простого Alt-[1-9] в терминале


 Можно переопределить в screenrc. Мне нравится

 escape `` # use ` instesd of Cntr-A

 обычно это клавиша перед регистром с числами
 и переключение сессий получается простым: `0 `1 `2 и т.д.
 Обратный апостроф (`) набирается двойным нажатием (``)


Кстати, посмотрел на tmux ещё раз - что мне нравится в нём, так это
статусная строка, не потеряешься, в screen иногда не понятно, в каком
уровень реальности я сейчас...


  В screen добавить строку состояния не проблема:
  ...
  # Status line: window list with the time and date
  hardstatus alwayslastline
  hardstatus string '%{= kG} %{G}%H %{g}[%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u
)%?%{r})%{w}%?%+Lw%?%?%= %{g}]%{D} %d/%m %c %{g}'
  ...

Ю.

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-17 Пенетрантность Tim Sattarov 
On 17/07/17 02:31 AM, Jurgen V. Uzbekoff wrote:
> Но ты спросил — я рассказываю про личный опыт. 
Понял, буду больше спрашивать :)
>> А разве в эмуляторе этого нет ? Зачем screen ?
> Может в каком-то эмуляторе это и есть. В моём текущем я не обнаружил (а до
> сегодняшнего дня даже и не пытался искать). И то, что я не пытался искать
> эту функцию не только в этом terminal-emulator, но и в других, в которых я
> запускал screen, мне очень нравится — мне в любом эмуляторе было
> достаточно привычного функционала screen.

у меня наверное проблема с быстрым переключением между сессиями: когда
вводить последовательность нажатий, для переключения между сессиями.
Против простого Alt-[1-9] в терминале

Кстати, посмотрел на tmux ещё раз - что мне нравится в нём, так это
статусная строка, не потеряешься, в screen иногда не понятно, в каком
уровень реальности я сейчас...

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-17 Пенетрантность Jurgen V. Uzbekoff 
On Fri, Jul 14, 2017 at 12:02:21PM -0400, Tim Sattarov wrote:
> On 14/07/17 01:15 AM, Jurgen V. Uzbekoff wrote:
> > Свои пять копеек. Про screen, но не суть:
> Привет ! давно тебя здесь не видел :)

Ну так я в режиме Read-Only обычно :)

Тут за выходные умные люди столько всего написали хорошего, чем я никогда
даже и не думал пользоваться… Но ты спросил — я рассказываю про личный
опыт.

> > 1. Есть несколько конкретных табов с конкретными задачами — переключаюсь в
> > нужный на автопилоте;
> > 2. Очень полезен большой scrollback и поиск/копирование в нём;
> А разве в эмуляторе этого нет ? Зачем screen ?

Может в каком-то эмуляторе это и есть. В моём текущем я не обнаружил (а до
сегодняшнего дня даже и не пытался искать). И то, что я не пытался искать
эту функцию не только в этом terminal-emulator, но и в других, в которых я
запускал screen, мне очень нравится — мне в любом эмуляторе было
достаточно привычного функционала screen.

> > 3. В terminal-emulator есть и свои табы — их по числу постоянных удалённых
> > соединений, плюс один локальный; а в каждом из них свой набор
> > мультиплексированных терминалов (не совсем локальный сценарий, каюсь);
> я в своих скриптах, когда нужно заходить на машину(ы) за бастионом
> (jump-server, bastion) открываю локальную сессию screen с подключением к
> бастиону и подключением к остальным серверам из списка. Удобно да. Плюс
> журналированине сессии в файл и портирование скрипта на другие платформы
> становится немного легче.
> Ну и стандартное использование: открыть screen для критичной/долгой
> операции на удалённом сервере, "штоб не порвалось посередине"
> 
> Мой вопрос больше, про: какая разница
> - запустить терминал с кучей вкладок и перейти в нужные папки/запустить
> нужную программу
> или
> - запустить локальный screen/tmux всё с теми же программами ?

В screen автомагически имеешь набор табов, где за меня уже перешли в нужные
папки и запустили нужные программы. Кроме того, всё-таки, очень полезно
иметь возможность подключиться к этому набору откуда угодно и чувствовать
себя как дома :)

> (это наверное подразумевает, графический терминал, в то же время
> tmux/screen менее требовательны)

И это тоже. Тут даже бОльшее преимущество в том, что собственно от
терминала не требуется практически ничего — он всего лишь должен иметь
возможность запустить screen.

-- 
IOpuk.

Re: tmux на локальной машине

2017-07-16 Пенетрантность Sergey Matveev 
*** Victor Wagner  [2017-07-16 21:00]:
>Опасной может быть даже команда cd.
>cd something; rm -rf *
>Мораль - всегда проверяйте exit code команды cd, а лучше
>в начале любого скрипта пишите set -e.

Если делать скрипт, то я всеми руками за set -e. Опасна в вашем примере
не команда cd, а rm -rf, а дальше уже действительно аккуратная проверка
всего вокруг неё.

>Вот нужно делать даже наколеночные скрипты правильно. Чтобы они упали,
>не успев навредить.

Если речь про tmux и screen, то повторюсь: нужно думать что писать,
думать что автоматизируется путём интерактивного ввода. Не нужно делать
из мухи слона и страдать из-за тучи shell файлов. Не нужно делать то,
что может навредить. Если в tmux скриптах только cd, workon (virtualenv
для python), export, su, запуск mutt/mocp/cmus/dnetc/whatever -- они не
навредят, даже если что-то пошло не так. Не нужно сравнивать general
purpose скрипты, и особые простые для запуска сред в tmux.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: tmux на локальной машине

2017-07-16 Пенетрантность Victor Wagner 
On Sun, 16 Jul 2017 18:24:27 +0300
Sergey Matveev  wrote:

> *** Ivan Shmakov  [2017-07-16 18:04]:
> > Причем здесь доверие?  Я уже привел один пример: $ ssh REMOTE
> > может дать доступ к Shell на удаленной машине; а может —
> > предупреждение о том, что ключ REMOTE не соответствует
> > сохраненному в ~/.ssh/known_hosts.  Ни stuff, ни set-buffer +
> > paste-buffer адекватно эту ситуацию обработать, IIUC, не
> > позволяют.  
> 
> Тогда я не так понял что вы имели в виду прежде. Да, хороший пример.
> Просто никогда такие "опасные" команды в tmux не автоматизировал.
>

Опасной может быть даже команда cd.

Когда-то давно один мой знакоймый налетел на такую ситуацию:

У него был некоторый скрипт, который перегенерировал некоторое дерево
каталогов.  Скрипт начиланся с 

cd something; rm -rf *

Вот это something было расположено в его $HOME и являлось симлинком на
каталог на втором физическом диске (не помню уж куда этот диск был
смонтирован. На /srv какой-нибудь). Скрипт запускался по крону.

И вот однажды этот большой диск немножко умер. Поскольку это был
сервер, на нем как могли переконфигуировали сервисы и подняли с одним
диском. Про этот скрипт, бывший частным делом одного из сотрудников
компании, который в офисе в  момент неприятности не случился,
естественно забыли.

Скрипт запустился, перейти по висячему симлинку не смог и выполнил

rm -rf прямо в $HOME этого товарища.

Мораль - всегда проверяйте exit code команды cd, а лучше
в начале любого скрипта пишите set -e.

> Ну для меня это "болезнь" людей которые любят bleeding edge.
> Обновляться надо аккуратно, читая changelog-и софта. Хотя по ним не
> всегда понятно затронет ли оно "меня" или нет. В любом случае всё это
> настолько редкие для меня ситуации, что о них даже не собираюсь
> думать.

Вот делаешь dist-upgrade, обновляются пара тысяч пакетов, а ты потом
разбирайся, где оно поехало, а где нет. 

 
> Есть разница между "делать всё правильно" и сделать всё очень быстро,
> наколеночные макросы и простые скрипты которые экономят время, пускай
> даже которые упадут или не сработают. Время настройки автоматически

Вот нужно делать даже наколеночные скрипты правильно. Чтобы они упали,
не успев навредить.

Re: tmux на локальной машине

2017-07-16 Пенетрантность Sergey Matveev 
*** Ivan Shmakov  [2017-07-16 18:04]:
>   Причем здесь доверие?  Я уже привел один пример: $ ssh REMOTE
>   может дать доступ к Shell на удаленной машине; а может —
>   предупреждение о том, что ключ REMOTE не соответствует
>   сохраненному в ~/.ssh/known_hosts.  Ни stuff, ни set-buffer +
>   paste-buffer адекватно эту ситуацию обработать, IIUC, не
>   позволяют.

Тогда я не так понял что вы имели в виду прежде. Да, хороший пример.
Просто никогда такие "опасные" команды в tmux не автоматизировал.

>   Еще одна возможная ситуация — «внезапное» изменение умолчаний.

Ну для меня это "болезнь" людей которые любят bleeding edge. Обновляться
надо аккуратно, читая changelog-и софта. Хотя по ним не всегда понятно
затронет ли оно "меня" или нет. В любом случае всё это настолько редкие
для меня ситуации, что о них даже не собираюсь думать.

>   А если так, то в чем преимущество set-buffer + paste-buffer
>   перед, например, $ bash --rcfile=?  (Предполагая, что
>   используется именно Bash.  Думаю, иные реализации Shell
>   предоставляют схожие возможности.)

(bash не использую, но это мелочи) Тут rcfile будет для одного
интерпретатора. Если мне нужно открыть несколько окон (pane-ов в tmux) и
в каждом из них что-то сделать своё, не одинаковое для всех окон, то
тогда нужно написать несколько rc-файлов. Вместо ровно одного, где всё
сконсолидировано -- нужно иметь и скрипт с tmux/screen обёрткой и
отдельные rc-файлы. Да, можно их поместить и в один, который их сохранит
во временные файлы, натравливая на них shell, но... это уже не удобно,
это уже костыли. Мне надо думать как делать --rcfile, а мне хочется
просто ручные действия "заскриптовать".

>   /Цель/ работы данного кода, как я ее понял, — дать пользователю
>   root-доступ, если «подключен зашифрованный диск».

Нет, просто ввести "su -" и пароль взятый с диска. Если пароля нет, то
он введёт пустоту и su меня пошлёт. Просто ввести su и пароль -- мне не
надо никаких проверок.

>   Я не вижу причины, по которой некий «шлюз привилегий» не может
>   проверить факт /наличия/ файла — и дать root-доступ без
>   необходимости ввода какого-либо пароля.  (Или хранения оного.)

Для этого мне надо открыть документацию su/sudo/doas/whatever и смотреть
может ли он это сделать. Мне этого не надо -- мне надо просто повторить
мои ручные действия.

Есть разница между "делать всё правильно" и сделать всё очень быстро,
наколеночные макросы и простые скрипты которые экономят время, пускай
даже которые упадут или не сработают. Время настройки автоматически
запускаемого рабочего окружения с "правильными" подходами в виде
rc-файлов, проверок на ошибки и прочего существенно больше чем просто
сказать что надо интерактивно ввести. Если что-то пошло не так, то проще
поправить скрипт.

Тут точно так же как при работе в Vim редакторе: не всегда "делать
правильно" эффективно по времени -- иногда надо делать менее эффективно,
но зато с меньшими усилиями, если что, если например макрос "испорчен",
то с нуля его повторить.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: tmux на локальной машине

2017-07-16 Пенетрантность Ivan Shmakov 
> Sergey Matveev  writes:
> *** Ivan Shmakov  [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
 >

Re: tmux на локальной машине

2017-07-16 Пенетрантность Ivan Shmakov 
> Sergey Matveev  writes:
> *** Ivan Shmakov  [2017-07-16 09:25]:

 >> Что понимается под «vi-like клавишами для поиска»?  Поскольку Screen
 >> вроде бы умеет как «наращиваемый» Emacs-like поиск (C-r, C-s), так и
 >> «традиционный» (/, ?).  Равно как и hjkl.

 > В дополнении к "/", "?" ещё клавиши типа "%", "{", "}", "f", итд.
 > Хотя это уже скорее просто перемещение, а не поиск.

Команды перемещения у Screen, разумеется, тоже есть; Less-like,
если угодно; % — в начало буфера; G — в конец; etc.

Мне не приходилось участвовать в разработке GNU Screen, но не
вижу причин считать, что предложения «добавить Vi-клавиш» будут
заведомо отвергнуты разработчиками.  Разве что из соображений
«обратной совместимости».

 >> Я так понимаю, здесь запускается окно с Shell, в которое затем
 >> вводится $ su -?  Честно говоря, я обычно $ screen 10 su -, без
 >> каких-либо промежуточных интерпретаторов.

 > Плюс оно бьётся по pane-ам,

Не вижу препятствий для неинтерактивного использования split и в
Screen.  Я, однако, редко использую «многооконность» самого
Screen (куда чаще — запущенного в нем Emacs.)

 > переходит в директории.

Я бы решил это так:

### my.screen

chdir /foo
screen -t foo 3

chdir /bar
screen -t bar 8

chdir /baz
screen -t baz 17 qux --quux

chdir

### my.screen ends here

 > Когда-то я сразу и mutt и mocp запускал.

Это может составить какую-либо проблему для Screen?

 >> $ cat < setup-slogin.screen

 > Тут вроде всё выглядит так, что запускается только ровно одна
 > команда?

Именно.  Никакой «имитации интерактивности» — исключительно
«штатные» интерфейсы.

В общем случае, это кажется куда как более надежным.  Мало ли о
чем запущенное приложение захочет спросить пользователя сразу
после запуска?  SSH-клиент, например, может предупреждение о
возможном MitM выдать — и попросить подтвердить доступ.  Или, в
отсутствие ключа у агента — пароль спросить.

 > В tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего?

?  Это вопрос?

 > На самом деле кроме "su -" ещё и его пароль вставляется (загруженный
 > с зашифрованного диска — мол если диск подключен, то это уж точно
 > авторизованный пользователь).

… Любопытно, а умеет ли sudo(8) учитывать факт наличия
произвольных файлов при выполнении авторизации?

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: tmux на локальной машине

2017-07-16 Пенетрантность Sergey Matveev 
Опять же, не знаю как в screen, но в tmux я активно использую штуку
когда по нажатию сочетания клавиш, он мне во временный файл сохраняет
содержимое текущего pane, открывает ещё один pane, а в нём команду
натравленную на временный файл:

bind-key u capture-pane -J \;
save-buffer /tmp/tmux-buffer \;
split-window 'urlview /tmp/tmux-buffer' \;
delete-buffer
bind-key y capture-pane -J \;
save-buffer /tmp/tmux-buffer \;
split-window 'vim /tmp/tmux-buffer' \;
delete-buffer

например я в терминале вижу ссылку и мне хочется её открыть в броузере.
Нажимаю Prefix-u и мне открывается новое окно (pane) в котором urlview
позволяет выбрать ссылку и нажать enter, закрыв это окно. Или хочется
как-то вырезать/обработать текст который вижу на экране, но удобно сразу
же в текстовом редакторе -- нажимаю Prefix-y и у меня новый pane, в
котором vim с уже вставленным содержанием pane на котором я нажал
сочетание.

Видел use-case у пользователя с Gvim-ом: обычно всякие сообщения об
ошибках компиляции в формате "filename:lineno:colno". Так вот, опять же,
простое сочетание запускает sed/whatever который готовит вывод для
диалога предлагающего открыть обнаруженные на экране строчки, выбрав
нужную, он посылает команду ":e filename +lineno" в Gvim (он же, как бы,
клиент-серверный).

У меня когда-то был use-case чтобы всякие "#666" открывать в броузере
как ссылку для Redmine.

Я точно знаю что выбор ссылок или вот что-то сделать с отпарсенными
значениями можно и в urxvt, в котором на Perl можно скриптовать, но я не
понимаю зачем. Наверняка в любой системе есть screen/tmux, так почему бы
это не сделать в них? Терминал может поменяться от системы к системе, а
tmux всегда будет точно такой же родной с собой. Лично я вот люблю не
монстров типа gnome-terminal, а что-то очень простое, suckless, типа st
(st.suckless.org). А без tmux/whatever все эти хотелки требуют
прожорливых огромных монстров терминалов.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: tmux на локальной машине

2017-07-16 Пенетрантность Sergey Matveev 
*** Tim Sattarov  [2017-07-16 04:59]:
>У меня тоже был вопрос про разницу в предпочтениях, я в своё время начал
>пользоваться screen и как то с tmux после не пошло...

Я когда-то пользовался screen, но всегда, мягко говоря, ненавидел все их
сочетания клавиш и вообще подходы к конфигурации. А с tmux-ом вздохнул
спокойно. Но это личные предпочтения.

>На что только люди не идут, чтобы не пользоваться docker-compose
>(Продолжаю мощные вбросы :) )

Да уж, учитывая то, что я когда-то владел boycottdocker.org доменом :-)

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: tmux на локальной машине

2017-07-16 Пенетрантность Sergey Matveev 
*** Ivan Shmakov  [2017-07-16 09:25]:
>   Что понимается под «vi-like клавишами для поиска»?  Поскольку
>   Screen вроде бы умеет как «наращиваемый» Emacs-like поиск
>   (C-r, C-s), так и «традиционный» (/, ?).  Равно как и hjkl.

В дополнении к "/", "?" ещё клавиши типа "%", "{", "}", "f", итд. Хотя
это уже скорее просто перемещение, а не поиск.

>   Я так понимаю, здесь запускается окно с Shell, в которое затем
>   вводится $ su -?  Честно говоря, я обычно $ screen 10 su -, без
>   каких-либо промежуточных интерпретаторов.

Плюс оно бъётся по pane-ам, переходит в директории. Когда-то я сразу и
mutt и mocp запускал.

>$ cat < setup-slogin.screen 

Тут вроде всё выглядит так, что запускается только ровно одна команда? В
tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего? На
самом деле кроме "su -" ещё и его пароль вставляется (загруженный с
зашифрованного диска -- мол если диск подключен, то это уж точно
авторизованный пользователь).

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: tmux на локальной машине

2017-07-16 Пенетрантность Ivan Shmakov 
> Sergey Matveev  writes:
> *** Ivan Shmakov  [2017-07-15 20:28]:

 >>> Куда более удобной конфигурацией и скриптованием, хотя это наверное
 >>> субъективно.  Существенно меньшими размерами (хотя в GNU Screen
 >>> больше фич, типа работы с последовательными консолями).  vi-like
 >>> клавишами для поиска.

 >> Конкретнее?

 > Конкретнее что?

Что понимается под «vi-like клавишами для поиска»?  Поскольку
Screen вроде бы умеет как «наращиваемый» Emacs-like поиск
(C-r, C-s), так и «традиционный» (/, ?).  Равно как и hjkl.

 > Удобство?  Вот один из скриптов, который неплохо читается.

 > #!/bin/sh
 > paste()
 > {
 > local pane="$1"
 > local cmd="$2"
 > $TMUX set-buffer "$cmd"
 > $TMUX paste-buffer -t "$pane"
 > $TMUX delete-buffer
 > $TMUX send-keys -t "$pane" Enter
 > }
 > $TMUX new-session -d -s root
 > $TMUX rename-window -t root:1 "su"
 > $TMUX split-window -t root:1
 > $TMUX split-window -h -t root:1
 > $TMUX split-window -h -t root:1.0
 > paste root:1.0 "ssh-add-mass"
 > paste root:1.1 "su -"

Я так понимаю, здесь запускается окно с Shell, в которое затем
вводится $ su -?  Честно говоря, я обычно $ screen 10 su -, без
каких-либо промежуточных интерпретаторов.

Аналогично с запуском SSH-клиентов; подобно:

$ cat < setup-slogin.screen 
screen -t bobgu# 43 slogin root@bobgu
screen -t kelas# 42 slogin root@kelas
screen -t nevuf# 41 slogin root@nevuf
screen -t bobgu  33 slogin bobgu
screen -t kelas  32 slogin kelas
screen -t nevuf  31 slogin nevuf
$ screen -X source setup-slogin.screen 
$ 

[…]

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: tmux на локальной машине

2017-07-15 Пенетрантность Tim Sattarov 
У меня тоже был вопрос про разницу в предпочтениях, я в своё время начал
пользоваться screen и как то с tmux после не пошло...

On 15/07/17 01:47 PM, Sergey Matveev wrote:
> аналогично есть скрипты которые запускают рабочее окружение:
> postgresql, redis, переходят в директории, делают virtualenv (если
> python проект), бьют нужным образом окна и их именуют.
На что только люди не идут, чтобы не пользоваться docker-compose
(Продолжаю мощные вбросы :) )

> Как автоматизировать запуск обычного GUI терминала и в нём ввести
> всякие команды, открыть нужные табы, назвать их, итд? Это значит
> терминал должен поддерживать какой-то API и его надо бы вызывать. Я
> даже не знаю есть ли такое в них, но это будет terminal/vendor-lockin.
> А с tmux/screen можно заменить эмулятор терминала не трогая
> автоматизацию с terminal-specific API.

Я в своё время запускал несколько терминалов либо с разными табами, либо
с разными окнами
чтобы заполнить экран либо открыть рабочие сессии. Особого знания "API "
не нужно, простой man gnome-terminal или что там тогда было.

vim bindings это конечно сооблазнительно, а простые сочетания для поиска
в буфере есть у многих терминалов.

Всё сводится, на мой взгляд, к личным предпочтениям.
У меня давно назревал более общий вопрос про личные настройки, наверное
задам его отдельным тредом.
Спасибо

Re: tmux на локальной машине

2017-07-15 Пенетрантность Ivan Shmakov 
> Artem Chuprina  writes:
> Ivan Shmakov -> debian-russian@ @ Fri, 14 Jul 2017 20:00:32 +:

[…]

 >>> SSHVARS="SSH_CLIENT SSH_TTY SSH_AUTH_SOCK SSH_CONNECTION DISPLAY"

 >>> for x in ${SSHVARS} ; do
 >>> (eval echo $x=\$$x) | sed  's/=/="/
 >>> s/$/"/
 >>> s/^/export /'

 >> Bash позволил бы обойтись без eval ("${x}=${!x}"), но, похоже, POSIX
 >> такую подстановку не регламентирует.

 >> … Однако вполне можно обойтись без Sed:

 >> eval echo export "$x"=\\\'\${"$x"//\\\'/\\\'\\\'\\\'}\\\'

 > Ой...  Спасибо, я лучше sed.  То, что написано у меня, я хотя бы
 > прочесть в состоянии...

«Нечитаемая» часть моего варианта относится не к замене Sed, а к
обработке всех возможных имен файлов.  Другими словами —
содержащих одинарные кавычки (всюду заменяемые на «'\''»):

$ XYZ=/a\'b\ c\*\'d 
$ x=XYZ 
$ eval echo export "$x"=\\\'\${"$x"//\\\'/\\\'\\\'\\\'}\\\' 
export XYZ='/a'\''b c*'\''d'
$ 

Если этого не требуется — убираем подстановку с заменой
${(имя)//(шаблон)/(замена)}:

   eval echo export "$x"=\\\'\$"$x"\\\'

Или же (по вкусу):

   eval echo export "$x=\\'\$$x\\'"

Cf. исходный eval:

   eval echo $x=\$$x

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: tmux на локальной машине

2017-07-15 Пенетрантность Artem Chuprina 
Ivan Shmakov -> debian-russian@lists.debian.org  @ Fri, 14 Jul 2017 20:00:32 
+:

 >> zsh% cat ~/etc/bin/ssh 
 >> #!/bin/sh
 >> [ -n "$STY" ] && [ -f "$HOME/bin/fixssh" ] && . "$HOME/bin/fixssh"
 >> exec /usr/bin/$(basename $0) "$@"

 >  Откуда такая нелюбовь к содержащим пробелы именам файлов
 >  (в частности: $HOME)?

 >exec /usr/bin/"${0##*/}" "$@"

Звыняй, малость на коленке писалось. Боюсь, что еще на телефоне, там
экран маленький (физически). Там и не такое может быть...

 >> zsh% cat ~/etc/bin/grabssh 
 >> #!/bin/sh
 >> [ -z "$STY" ] || exit 1
 >> [ -d $HOME/bin ] || mkdir $HOME/bin

 >  Аналогично.  И более того.

 > [ -d "$HOME"/bin ] || mkdir -- "$HOME"/bin

 >  Вообще говоря, я следую весьма простому правилу: $ в "", кроме
 >  случаев, когда /требуется/ деление на слова.

 >> SSHVARS="SSH_CLIENT SSH_TTY SSH_AUTH_SOCK SSH_CONNECTION DISPLAY"

 >> for x in ${SSHVARS} ; do
 >> (eval echo $x=\$$x) | sed  's/=/="/
 >> s/$/"/
 >> s/^/export /'

 >  Bash позволил бы обойтись без eval ("${x}=${!x}"), но, похоже,
 >  POSIX такую подстановку не регламентирует.

 >  … Однако вполне можно обойтись без Sed:

 > eval echo export "$x"=\\\'\${"$x"//\\\'/\\\'\\\'\\\'}\\\'

Ой... Спасибо, я лучше sed. То, что написано у меня, я хотя бы прочесть
в состоянии...

Re: tmux на локальной машине

2017-07-15 Пенетрантность Sergey Matveev 
*** Ivan Shmakov  [2017-07-15 20:28]:
> > Куда более удобной конфигурацией и скриптованием, хотя это наверное
> > субъективно.  Существенно меньшими размерами (хотя в GNU Screen
> > больше фич, типа работы с последовательными консолями).  vi-like
> > клавишами для поиска.
>
>   Конкретнее?

Конкретнее что? Удобство? Вот один из скриптов, который неплохо читается.

#!/bin/sh
paste()
{
local pane="$1"
local cmd="$2"
$TMUX set-buffer "$cmd"
$TMUX paste-buffer -t "$pane"
$TMUX delete-buffer
$TMUX send-keys -t "$pane" Enter
}
$TMUX new-session -d -s root
$TMUX rename-window -t root:1 "su"
$TMUX split-window -t root:1
$TMUX split-window -h -t root:1
$TMUX split-window -h -t root:1.0
paste root:1.0 "ssh-add-mass"
paste root:1.1 "su -"
paste root:1.1 "cd /home/stargrave/work/govpn"
paste root:1.2 "su -"
paste root:1.3 "su -"
$TMUX new-window -t root:2 -n email
$TMUX new-window -t root:3 -n music
paste root:3 "cd tmp/music"
$TMUX new-window -t root:4 -n dnetc
paste root:4 "cd data/dnetc521-freebsd10-amd64"
$TMUX select-window -t root:1.0

аналогично есть скрипты которые запускают рабочее окружение:
postgresql, redis, переходят в директории, делают virtualenv (если
python проект), бьют нужным образом окна и их именуют.

> > Судя по всему к screen нельзя подключиться несколькими клиентами
> > (несколько людей смотрят в одну сессию), а это killer-feature.

Если можно, то ok.

> > Я так точно и не понял, но есть ли в screen-е vertical pane
> > разделение?

Ok, если есть вертикальный split.

Если screen всё это умеет, то тогда (не считая размера), вопрос вкуса
наверное.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: tmux на локальной машине

2017-07-15 Пенетрантность Ivan Shmakov 
> Sergey Matveev  writes:
> *** Artem Chuprina  [2017-07-15 18:59]:

[…]

 >> Чем, кстати, tmux лучше, чем screen?

 > Куда более удобной конфигурацией и скриптованием, хотя это наверное
 > субъективно.  Существенно меньшими размерами (хотя в GNU Screen
 > больше фич, типа работы с последовательными консолями).  vi-like
 > клавишами для поиска.

Конкретнее?

 > Судя по всему к screen нельзя подключиться несколькими клиентами
 > (несколько людей смотрят в одну сессию), а это killer-feature.

$ cat < .screenrc
…

multiuser   on

…
## allow myself to do everything
acladd  ivan

## Let Screen know some users beside myself.
aclchg  john,smith  +x detach

## allow everybody to use a few more commands
aclchg  * +x license,version,help,displays
aclchg  * +x stuff,colon
aclchg  * +x select,next,prev
aclchg  * +x windows,info,dinfo
aclchg  * +x split,focus,only,remove

aclumask-rw ivan+rw
aclumask?-rw ??-x
…
$ 

Оговорюсь, однако, что настройки выше у меня в ~/.screenrc по
меньшей мере с 2004 г.  И примерно тогда же использовались в
последний раз.

 > Я так точно и не понял, но есть ли в screen-е vertical pane
 > разделение?

Согласно (screen) 5.1 Default Key Bindings:

‘C-a |’
 (split -v)
 Split the current region vertically into two new ones.

 > Можно ли в screen послать в любой pane какую-то последовательность
 > клавиш, что, опять же при скриптовании, очень удобно и гибко?

Только в текущее окно, AIUI.

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-15 Пенетрантность Sergey Matveev 
*** Artem Chuprina  [2017-07-15 18:59]:
>Зато у тебя будет screen/tmux vendor lock-in. Или tmux счел, что API
>screen — стандарт де-факто, и поддерживает его?

Терминалов -- десятки видов, а GNU screen один и tmux один. За свою
жизнь я много терминалов сменил, а вот tmux не на что, ни разу.

>Чем, кстати, tmux лучше, чем screen?

Куда более удобной конфигурацией и скриптованием, хотя это наверное
субъективно. Существенно меньшими размерами (хотя в GNU screen больше
фич, типа работы с последовательными консолями). vi-like клавишами для
поиска. Судя по всему к screen нельзя подключиться несколькими клиентами
(несколько людей смотрят в одну сессию), а это killer-feature. Я так
точно и не понял, но есть ли в screen-е vertical pane разделение? Можно
ли в screen послать в любой pane какую-то последовательность клавиш,
что, опять же при скриптовании, очень удобно и гибко?

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-15 Пенетрантность Artem Chuprina 
Sergey Matveev -> debian-russian@lists.debian.org  @ Fri, 14 Jul 2017 19:21:01 
+0300:

 > *** Tim Sattarov  [2017-07-14 19:10]:
 >>> 2. Очень полезен большой scrollback и поиск/копирование в нём;
 >>А разве в эмуляторе этого нет ? Зачем screen ?

 > Ни того, ни другого нет например в st терминале (http://st.suckless.org/).
 > А в каком-нибудь urxvt я не помню чтобы в буфере можно было искать
 > текст, перемещаться по нему vim-binding-ами.

А я, кстати, упустил, что в screen можно искать по буферу... Копировать
да, копирую, а вот чтобы искать...

 >>Мой вопрос больше, про: какая разница
 >>- запустить терминал с кучей вкладок и перейти в нужные папки/запустить
 >>нужную программу
 >>или
 >>- запустить локальный screen/tmux всё с теми же программами ?

 > Как автоматизировать запуск обычного GUI терминала и в нём ввести всякие
 > команды, открыть нужные табы, назвать их, итд? Это значит терминал
 > должен поддерживать какой-то API и его надо бы вызывать. Я даже не знаю
 > есть ли такое в них, но это будет terminal/vendor-lockin. А с
 > tmux/screen можно заменить эмулятор терминала не трогая автоматизацию с
 > terminal-specific API.

Зато у тебя будет screen/tmux vendor lock-in. Или tmux счел, что API
screen — стандарт де-факто, и поддерживает его?

Чем, кстати, tmux лучше, чем screen?

Я, кстати, подумываю о том, чтобы у меня все-таки был единый
интерфейс. А то Ctrl-A то работает сразу, то управляет screen'ом, в
зависимости от того, удаленный хост или локальный...

Re: tmux на локальной машине

2017-07-15 Пенетрантность Ivan Shmakov 
> Artem Chuprina  writes:
> Ivan Shmakov -> debian-russian@ @ Sat, 15 Jul 2017 08:35:19 +:

  Собственно, в ~/bin/fixssh получается

  export SSH_CLIENT="127.0.0.1 43717 22"
  export SSH_TTY="/dev/pts/1"
  export SSH_AUTH_SOCK="/tmp/ssh-7olChLovwG/agent.6998"
  export SSH_CONNECTION="127.0.0.1 43717 127.0.0.1 22"
  export DISPLAY=""

  Подозреваю, что в комплекте с keychain получится и решение первой
  задачи.  Мне просто unattended не надо, я и не проверял.

 >>> Любопытно, каким образом используются переменные выше, кроме
 >>> SSH_AUTH_SOCK и SSH_CONNECTION?

 >> !  s/SSH_CONNECTION/DISPLAY/, разумеется.

 > Я тупо сдернул все, что начиналось с SSH.  Мало ли, кто их хочет...

Я так думаю, что лишь у очень немногих программ действительно
найдется веская причина выяснять, а не по SSH ли их используют,
и если так, то где находится клиент?

Меня бы такое любопытство со стороны используемой мной программы
— насторожило.

FWIW,

$ grep -F -- SSH_ < .screenrc 
unsetenvSSH_CLIENT
unsetenvSSH_CONNECTION
unsetenvSSH_TTY
$ 

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: tmux на локальной машине

2017-07-15 Пенетрантность Artem Chuprina 
Ivan Shmakov -> debian-russian@lists.debian.org  @ Sat, 15 Jul 2017 08:35:19 
+:

 >>> Собственно, в ~/bin/fixssh получается

 >>> export SSH_CLIENT="127.0.0.1 43717 22"
 >>> export SSH_TTY="/dev/pts/1"
 >>> export SSH_AUTH_SOCK="/tmp/ssh-7olChLovwG/agent.6998"
 >>> export SSH_CONNECTION="127.0.0.1 43717 127.0.0.1 22"
 >>> export DISPLAY=""

 >>> Подозреваю, что в комплекте с keychain получится и решение первой
 >>> задачи.  Мне просто unattended не надо, я и не проверял.

 >> Любопытно, каким образом используются переменные выше, кроме
 >> SSH_AUTH_SOCK и SSH_CONNECTION?

 >  !  s/SSH_CONNECTION/DISPLAY/, разумеется.

Я тупо сдернул все, что начиналось с SSH. Мало ли, кто их хочет...

Re: tmux на локальной машине

2017-07-15 Пенетрантность Ivan Shmakov 
> Ivan Shmakov  writes:
> Artem Chuprina  writes:

[…]

 >> Собственно, в ~/bin/fixssh получается

 >> export SSH_CLIENT="127.0.0.1 43717 22"
 >> export SSH_TTY="/dev/pts/1"
 >> export SSH_AUTH_SOCK="/tmp/ssh-7olChLovwG/agent.6998"
 >> export SSH_CONNECTION="127.0.0.1 43717 127.0.0.1 22"
 >> export DISPLAY=""

 >> Подозреваю, что в комплекте с keychain получится и решение первой
 >> задачи.  Мне просто unattended не надо, я и не проверял.

 > Любопытно, каким образом используются переменные выше, кроме
 > SSH_AUTH_SOCK и SSH_CONNECTION?

!  s/SSH_CONNECTION/DISPLAY/, разумеется.

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Re: tmux на локальной машине

2017-07-14 Пенетрантность Ivan Shmakov 
> Sergey Matveev  writes:
> *** Tim Sattarov  [2017-07-14 19:10]:

 >>> 2. Очень полезен большой scrollback и поиск/копирование в нём;

 >> А разве в эмуляторе этого нет ? Зачем screen ?

 > Ни того, ни другого нет например в st терминале
 > (http://st.suckless.org/).

У suckless нет и много чего еще.  Я был бы весьма за slock, если
бы его можно было бы использовать вместе с Kerberos.  Хотя,
подозреваю, i18n окажется даже более слабым местом.

 > А в каком-нибудь urxvt я не помню чтобы в буфере можно было искать
 > текст, перемещаться по нему vim-binding-ами.

XTerm такой возможности тоже как будто бы не предоставляет.
Весьма удобно, между прочим, e. g. (в умолчаниях GNU Screen):

C-a [ C-r XXX ESC RET C-s YYY ESC h RET — скопировать от XXX (включая)
до YYY (не включая.)

 >> Мой вопрос больше, про: какая разница — запустить терминал с кучей
 >> вкладок и перейти в нужные папки/запустить нужную программу или —
 >> запустить локальный screen/tmux всё с теми же программами ?

 > Как автоматизировать запуск обычного GUI терминала и в нём ввести
 > всякие команды, открыть нужные табы, назвать их, итд?  Это значит
 > терминал должен поддерживать какой-то API и его надо бы вызывать.
 > Я даже не знаю есть ли такое в них, но это будет
 > terminal/vendor-lockin.  А с tmux/screen можно заменить эмулятор
 > терминала не трогая автоматизацию с terminal-specific API.

Ну да, будет использоваться Screen- или Tmux-specific API,
вместе с соответствующим lock-in.

-- 
FSF associate member #7257  np. To Catch a Falling Star — Forest Rain

Re: tmux на локальной машине

2017-07-14 Пенетрантность Ivan Shmakov 
> Artem Chuprina  writes:
> Victor Wagner -> debian-russian@ @ Thu, 13 Jul 2017 22:34:51 +0300:

[…]

 >> 1. Придумать удобный, желательно zero-key solution, чтобы при
 >> запуске screen там образовывался свой агент со своими ключами, по
 >> которым пускают только на гитхаб или тому подобные сайты, куда может
 >> понадобится скрипту без человеческого надзора ходить.

Если грубо…

#!/bin/sh
## Usage: $ eval "$(get-agent)"

## Check if SSH_AUTH_SOCK is already set
test -n "$SSH_AUTH_SOCK" \
&& exit

## NOTE that we may decide to REMOVE this file later in this script.
## Getting this one from the environment may have security implications.
export SSH_AUTH_SOCK="$HOME"/.ssh-agent/"$HOSTNAME".socket

## Check if ssh-agent(1) can be interacted with
ssh-add -l > /dev/null
if test "$?" != 2 ; then
## NB: $? should either be 0 (OK) or 1 (command failed; say, due to
## the agent currently representing NO identities) here
printf %s\\n SSH_AUTH_SOCK="'${SSH_AUTH_SOCK//\'/\'\\\'\'}'"
exit
fi

## Move stale socket out of our way
mv -f -- "$SSH_AUTH_SOCK" "${SSH_AUTH_SOCK}.~${RANDOM}~"
## Or we can remove it instead
# rm -f -- "$SSH_AUTH_SOCK"

## Pass control to a newly started agent
exec ssh-agent -a "$SSH_AUTH_SOCK"

 >> 2. Придумать способ как сделать, чтобы при реконнекте к screen-у у
 >> выполняющихся внутри его сессий процессов появлялся доступ к
 >> ssh-ключам той сессии, откуда выполнен реконнект.

 >> (похоже тут ничего не придумаешь кроме встраивания в мультиплексор
 >> терминалов своего agent-forwarder-а).

 > Ко второму у меня есть.  Правда, довольно навороченное.

[…]

 > zsh% cat ~/etc/bin/ssh 
 > #!/bin/sh
 > [ -n "$STY" ] && [ -f "$HOME/bin/fixssh" ] && . "$HOME/bin/fixssh"
 > exec /usr/bin/$(basename $0) "$@"

Откуда такая нелюбовь к содержащим пробелы именам файлов
(в частности: $HOME)?

   exec /usr/bin/"${0##*/}" "$@"

 > zsh% cat ~/etc/bin/grabssh 
 > #!/bin/sh
 > [ -z "$STY" ] || exit 1
 > [ -d $HOME/bin ] || mkdir $HOME/bin

Аналогично.  И более того.

[ -d "$HOME"/bin ] || mkdir -- "$HOME"/bin

Вообще говоря, я следую весьма простому правилу: $ в "", кроме
случаев, когда /требуется/ деление на слова.

 > SSHVARS="SSH_CLIENT SSH_TTY SSH_AUTH_SOCK SSH_CONNECTION DISPLAY"

 > for x in ${SSHVARS} ; do
 > (eval echo $x=\$$x) | sed  's/=/="/
 > s/$/"/
 > s/^/export /'

Bash позволил бы обойтись без eval ("${x}=${!x}"), но, похоже,
POSIX такую подстановку не регламентирует.

… Однако вполне можно обойтись без Sed:

eval echo export "$x"=\\\'\${"$x"//\\\'/\\\'\\\'\\\'}\\\'

 > done 1>$HOME/bin/fixssh

 > zsh% cat ~/etc/bin/screen 
 > #!/bin/sh
 > grabssh
 > exec /usr/bin/screen "$@"

 > Собственно, в ~/bin/fixssh получается

 > export SSH_CLIENT="127.0.0.1 43717 22"
 > export SSH_TTY="/dev/pts/1"
 > export SSH_AUTH_SOCK="/tmp/ssh-7olChLovwG/agent.6998"
 > export SSH_CONNECTION="127.0.0.1 43717 127.0.0.1 22"
 > export DISPLAY=""

 > Подозреваю, что в комплекте с keychain получится и решение первой
 > задачи.  Мне просто unattended не надо, я и не проверял.

Любопытно, каким образом используются переменные выше, кроме
SSH_AUTH_SOCK и SSH_CONNECTION?

-- 
FSF associate member #7257  np. Alone — Fox Amoore & Dreamsong  B6A0 230E 334A

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-14 Пенетрантность Igor Savlook 
On Fri, 2017-07-14 at 12:02 -0400, Tim Sattarov wrote:
> On 14/07/17 01:15 AM, Jurgen V. Uzbekoff wrote:
> > Свои пять копеек. Про screen, но не суть:
> 
> Привет ! давно тебя здесь не видел :)
> > 1. Есть несколько конкретных табов с конкретными задачами —
> > переключаюсь в
> > нужный на автопилоте;
> > 2. Очень полезен большой scrollback и поиск/копирование в нём;
> 
> А разве в эмуляторе этого нет ? Зачем screen ?

С screen/tmux можно сделать detach от теминала и уйти гулять (особенно
полезно на серверах хотя я юзаюи и на исках).

> > 3. В terminal-emulator есть и свои табы — их по числу постоянных
> > удалённых
> > соединений, плюс один локальный; а в каждом из них свой набор
> > мультиплексированных терминалов (не совсем локальный сценарий,
> > каюсь);
> 
> я в своих скриптах, когда нужно заходить на машину(ы) за бастионом
> (jump-server, bastion) открываю локальную сессию screen с
> подключением к
> бастиону и подключением к остальным серверам из списка. Удобно да.
> Плюс
> журналированине сессии в файл и портирование скрипта на другие
> платформы
> становится немного легче.
> Ну и стандартное использование: открыть screen для критичной/долгой
> операции на удалённом сервере, "штоб не порвалось посередине"
> 
> Мой вопрос больше, про: какая разница
> - запустить терминал с кучей вкладок и перейти в нужные
> папки/запустить
> нужную программу
> или
> - запустить локальный screen/tmux всё с теми же программами ?
> 
> (это наверное подразумевает, графический терминал, в то же время
> tmux/screen менее требовательны)
> 
>

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-14 Пенетрантность Sergey Matveev 
*** Tim Sattarov  [2017-07-14 19:10]:
>> 2. Очень полезен большой scrollback и поиск/копирование в нём;
>А разве в эмуляторе этого нет ? Зачем screen ?

Ни того, ни другого нет например в st терминале (http://st.suckless.org/).
А в каком-нибудь urxvt я не помню чтобы в буфере можно было искать
текст, перемещаться по нему vim-binding-ами.

>Мой вопрос больше, про: какая разница
>- запустить терминал с кучей вкладок и перейти в нужные папки/запустить
>нужную программу
>или
>- запустить локальный screen/tmux всё с теми же программами ?

Как автоматизировать запуск обычного GUI терминала и в нём ввести всякие
команды, открыть нужные табы, назвать их, итд? Это значит терминал
должен поддерживать какой-то API и его надо бы вызывать. Я даже не знаю
есть ли такое в них, но это будет terminal/vendor-lockin. А с
tmux/screen можно заменить эмулятор терминала не трогая автоматизацию с
terminal-specific API.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-14 Пенетрантность Tim Sattarov 
On 14/07/17 01:15 AM, Jurgen V. Uzbekoff wrote:
> Свои пять копеек. Про screen, но не суть:
Привет ! давно тебя здесь не видел :)
> 1. Есть несколько конкретных табов с конкретными задачами — переключаюсь в
> нужный на автопилоте;
> 2. Очень полезен большой scrollback и поиск/копирование в нём;
А разве в эмуляторе этого нет ? Зачем screen ?
> 3. В terminal-emulator есть и свои табы — их по числу постоянных удалённых
> соединений, плюс один локальный; а в каждом из них свой набор
> мультиплексированных терминалов (не совсем локальный сценарий, каюсь);
я в своих скриптах, когда нужно заходить на машину(ы) за бастионом
(jump-server, bastion) открываю локальную сессию screen с подключением к
бастиону и подключением к остальным серверам из списка. Удобно да. Плюс
журналированине сессии в файл и портирование скрипта на другие платформы
становится немного легче.
Ну и стандартное использование: открыть screen для критичной/долгой
операции на удалённом сервере, "штоб не порвалось посередине"

Мой вопрос больше, про: какая разница
- запустить терминал с кучей вкладок и перейти в нужные папки/запустить
нужную программу
или
- запустить локальный screen/tmux всё с теми же программами ?

(это наверное подразумевает, графический терминал, в то же время
tmux/screen менее требовательны)

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-13 Пенетрантность Jurgen V. Uzbekoff 
On Thu, Jul 13, 2017 at 01:28:33PM -0400, Tim Sattarov wrote:
> On 13/07/17 03:40 AM, Igor Savlook wrote:
> > Постоянно использую tmux на локальной машине с xfce. Вообще без него
> > жить немогу.
>  Интересно послушать сценарий, когда это может пригодиться

Свои пять копеек. Про screen, но не суть:
1. Есть несколько конкретных табов с конкретными задачами — переключаюсь в
нужный на автопилоте;
2. Очень полезен большой scrollback и поиск/копирование в нём;
3. В terminal-emulator есть и свои табы — их по числу постоянных удалённых
соединений, плюс один локальный; а в каждом из них свой набор
мультиплексированных терминалов (не совсем локальный сценарий, каюсь);
4. При необходимости можно подключиться удалённо и иметь привычное
окружение — пожалуй, самый труднореализуемый сценарий без использования
мультиплексора…

-- 
IOpuk.

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-13 Пенетрантность Artem Chuprina 
Victor Wagner -> debian-russian@lists.debian.org  @ Thu, 13 Jul 2017 22:34:51 
+0300:

 > А вот, кстати, не поделится ли кто опытом - как screen или tmux
 > правильно сочетать с ssh-агентом. А то большвя часть процессов, которые
 > хочется запустить в screen и уйти то ли от дисплея локальной машины,
 > разлогинившись, то ли с удаленного сервера, норовят на какой-нибудь
 > github по ssh ломиться.

 > Сейчас у меня агент запускается через pam-ssh, а потом форвародится
 > через все ssh-сессии. Естественно при завершении логинной сессии агент
 > исчезает и переменные SSH_AUTH_SOCK и SSH_AGENT_PID во всех сессиях
 > screen начинают показывать никуда.

 > (вообще у меня еще есть желание докрутить это дело до того, чтобы при
 > блокировке экрана light-locker-ом ключи бы из агента вычищались, а при
 > вводе пароля опять pam-ssh их бы туда клал.

 > Соответствено есть две разные проблемы:

 > 1. Придумать удобный, желательно zero-key solution, чтобы при запуске
 > screen там образовывался свой агент со своими ключами, по которым
 > пускают только на гитхаб или тому подобные сайты, куда может
 > понадобится скрипту без человеческого надзора ходить.

 > 2. Придумать способ как сделать, чтобы при реконнекте к screen-у у
 > выполняющихся внутри его сессий процессов появлялся доступ к ssh-ключам
 > той сессии, откуда выполнен реконнект.

 > (похоже тут ничего не придумаешь кроме встраивания в мультиплексор
 > терминалов своего agent-forwarder-а).

Ко второму у меня есть. Правда, довольно навороченное.

zsh% cat ~/etc/bin/git
#!/bin/sh
export GIT_SSH="$HOME/etc/bin/ssh"
exec /usr/bin/git "$@"

zsh% cat ~/etc/bin/ssh
#!/bin/sh
[ -n "$STY" ] && [ -f "$HOME/bin/fixssh" ] && . "$HOME/bin/fixssh"
exec /usr/bin/$(basename $0) "$@"

zsh% cat ~/etc/bin/grabssh 
#!/bin/sh
[ -z "$STY" ] || exit 1
[ -d $HOME/bin ] || mkdir $HOME/bin
SSHVARS="SSH_CLIENT SSH_TTY SSH_AUTH_SOCK SSH_CONNECTION DISPLAY"

for x in ${SSHVARS} ; do
(eval echo $x=\$$x) | sed  's/=/="/
s/$/"/
s/^/export /'
done 1>$HOME/bin/fixssh

zsh% cat ~/etc/bin/screen 
#!/bin/sh
grabssh
exec /usr/bin/screen "$@"

Собственно, в ~/bin/fixssh получается

export SSH_CLIENT="127.0.0.1 43717 22"
export SSH_TTY="/dev/pts/1"
export SSH_AUTH_SOCK="/tmp/ssh-7olChLovwG/agent.6998"
export SSH_CONNECTION="127.0.0.1 43717 127.0.0.1 22"
export DISPLAY=""

Подозреваю, что в комплекте с keychain получится и решение первой
задачи. Мне просто unattended не надо, я и не проверял.

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-13 Пенетрантность Alexander Galanin 
13.07.2017 22:34, Victor Wagner пишет:
> 2. Придумать способ как сделать, чтобы при реконнекте к screen-у у
> выполняющихся внутри его сессий процессов появлялся доступ к ssh-ключам
> той сессии, откуда выполнен реконнект.

В предположении, что пользователь одновременно работает только из одного
места, способ есть: https://gist.github.com/martijnvermaat/8070533

> (похоже тут ничего не придумаешь кроме встраивания в мультиплексор
> терминалов своего agent-forwarder-а).

А правильного решения никто не делает и живут с почти никого не
стесняющим вышеописанным ограничением.

-- 
Alexander Galanin

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-13 Пенетрантность Victor Wagner 
On Thu, 13 Jul 2017 21:59:04 +0300 (MSK)
yuri.nefe...@gmail.com wrote:


> 
>screen или tmux позволяют легко настраивать
>вкладки в xterm и работать с нужной конфигурацией.

А вот, кстати, не поделится ли кто опытом - как screen или tmux
правильно сочетать с ssh-агентом. А то большвя часть процессов, которые
хочется запустить в screen и уйти то ли от дисплея локальной машины,
разлогинившись, то ли с удаленного сервера, норовят на какой-нибудь
github по ssh ломиться.

Сейчас у меня агент запускается через pam-ssh, а потом форвародится
через все ssh-сессии. Естественно при завершении логинной сессии агент
исчезает и переменные SSH_AUTH_SOCK и SSH_AGENT_PID во всех сессиях
screen начинают показывать никуда.

(вообще у меня еще есть желание докрутить это дело до того, чтобы при
блокировке экрана light-locker-ом ключи бы из агента вычищались, а при
вводе пароля опять pam-ssh их бы туда клал.

Соответствено есть две разные проблемы:

1. Придумать удобный, желательно zero-key solution, чтобы при запуске
screen там образовывался свой агент со своими ключами, по которым
пускают только на гитхаб или тому подобные сайты, куда может
понадобится скрипту без человеческого надзора ходить.

2. Придумать способ как сделать, чтобы при реконнекте к screen-у у
выполняющихся внутри его сессий процессов появлялся доступ к ssh-ключам
той сессии, откуда выполнен реконнект.

(похоже тут ничего не придумаешь кроме встраивания в мультиплексор
терминалов своего agent-forwarder-а).

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-13 Пенетрантность yuri . nefedov 

On Thu, 13 Jul 2017, Tim Sattarov wrote:


On 13/07/17 03:40 AM, Igor Savlook wrote:

Постоянно использую tmux на локальной машине с xfce. Вообще без него
жить немогу.

Интересно послушать сценарий, когда это может пригодиться




  screen или tmux позволяют легко настраивать
  вкладки в xterm и работать с нужной конфигурацией.

  Например такой сценарий - код программы в src/, cmake запускается
  в build/, а программы выполняется в workdir/
  Удобно запустить screen c окошками в этих директориях -
  пишем в .screenrc.prg что-то типа

  # read in your normal screenrc before anything else
  source $HOME/.screenrc
  # change  the  current directory and start opening windows:
  chdir path/workdir
  screen -t workdir 2
  chdir path/build
  screen -t build 1
  chdir path/src
  screen -t src 0

  для большей лени прописываем элиас:
  alias screenprg='screen -c ~/.screenrc.prg'
  и вуаля...

Ю.

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-13 Пенетрантность Igor Savlook 
On Thu, 2017-07-13 at 21:25 +0300, Sergey Matveev wrote:
> *** Tim Sattarov <sti...@gmail.com> [2017-07-13 21:20]:
> > On 13/07/17 03:40 AM, Igor Savlook wrote:
> > > Постоянно использую tmux на локальной машине с xfce. Вообще без
> > > него
> > > жить немогу.
> > 
> > Интересно послушать сценарий, когда это может пригодиться
> 
> В терминале он предоставляет табы (tabs) и scrollback историю с
> поиском,
> плюс с удобными Vim клавишами навигации по ней -- можно использовать
> какой-нибудь простой терминал типа st (http://st.suckless.org/),
> множество буферов (а не один X11-овый), возможно заскриптовать запуск
> рабочего окружения (простым shell-скриптом задать как надо побить
> окна,
> именовать их, предварительно выполнить команды, итд). Я тоже не
> представляю жизни без tmux-а локально запускаемого ибо очень удобно.
> 
Вот и я также.

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-13 Пенетрантность Igor Savlook 
On Thu, 2017-07-13 at 13:28 -0400, Tim Sattarov wrote:
> On 13/07/17 03:40 AM, Igor Savlook wrote:
> > Постоянно использую tmux на локальной машине с xfce. Вообще без
> > него
> > жить немогу.
> 
>  Интересно послушать сценарий, когда это может пригодиться
> 
Использую вместе с xfce-terminal или просто в терминалах на серверах
чтобы не терять данные окошки и программы с какими работал, собсно для
разработки и просто для пары твойки копий mc очень даже.

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-13 Пенетрантность Sergey Matveev 
*** Tim Sattarov <sti...@gmail.com> [2017-07-13 21:20]:
>On 13/07/17 03:40 AM, Igor Savlook wrote:
>> Постоянно использую tmux на локальной машине с xfce. Вообще без него
>> жить немогу.
> Интересно послушать сценарий, когда это может пригодиться

В терминале он предоставляет табы (tabs) и scrollback историю с поиском,
плюс с удобными Vim клавишами навигации по ней -- можно использовать
какой-нибудь простой терминал типа st (http://st.suckless.org/),
множество буферов (а не один X11-овый), возможно заскриптовать запуск
рабочего окружения (простым shell-скриптом задать как надо побить окна,
именовать их, предварительно выполнить команды, итд). Я тоже не
представляю жизни без tmux-а локально запускаемого ибо очень удобно.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Re: tmux на локальной машине (was Xfce Terminal Emulator)

2017-07-13 Пенетрантность Tim Sattarov 
On 13/07/17 03:40 AM, Igor Savlook wrote:
> Постоянно использую tmux на локальной машине с xfce. Вообще без него
> жить немогу.
 Интересно послушать сценарий, когда это может пригодиться