Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Взбесился "Xfce Terminal Emulator
53 views
Skip to first unread message
fuf
Jul 12, 2017, 12:20:03 PM7/12/17
to
Салют всем!
Взбесился "Xfce Terminal Emulator"(xfce4-terminal 0.6.3). Как только нажимаешь букву f открывается новая вкладка в окне терминала и немедленно переключается печать туда, причём не важно в середине слова или нет нажимаешь букву f! Через Menu>File> увидел, что Open Tab F! Я удалял и вновь поставил (xfce4-terminal 0.6.3) через Synaptic- не помогло. Поставил Synaptic-ом "fbterm"-A fast framebuffer based terminal emulator for Linux, попробовал открыть его через Xterm и получил: ~$ fbterm
stdin isn't a interactive tty!
~$.
Прямо не знаю что делать. Может Synaptic-ом ещё что нибудь поставить? Там даже gnome-terminal есть, но у меня Xfce, и не известно будет ли работать, а загружать предлагается много МВ. Это первое в чём прошу помочь и подсказать.
------------------
У моего Xterm мельчайший шрифт, как увеличить? И прошу разъяснить как вообще настраивать терминалы (цвет, шрифт, и т.п.), я уже обращался насчёт раскладки, спасибо помогли тогда.
------------------
И не пойму почему в некоторых файлах используют `именно' такие кавычки, какое-то особое значение у них?
Спасибо.
Взбесился "Xfce Terminal Emulator"(xfce4-terminal 0.6.3). Как только нажимаешь букву f открывается новая вкладка в окне терминала и немедленно переключается печать туда, причём не важно в середине слова или нет нажимаешь букву f! Через Menu>File> увидел, что Open Tab F! Я удалял и вновь поставил (xfce4-terminal 0.6.3) через Synaptic- не помогло. Поставил Synaptic-ом "fbterm"-A fast framebuffer based terminal emulator for Linux, попробовал открыть его через Xterm и получил: ~$ fbterm
stdin isn't a interactive tty!
~$.
Прямо не знаю что делать. Может Synaptic-ом ещё что нибудь поставить? Там даже gnome-terminal есть, но у меня Xfce, и не известно будет ли работать, а загружать предлагается много МВ. Это первое в чём прошу помочь и подсказать.
------------------
У моего Xterm мельчайший шрифт, как увеличить? И прошу разъяснить как вообще настраивать терминалы (цвет, шрифт, и т.п.), я уже обращался насчёт раскладки, спасибо помогли тогда.
------------------
И не пойму почему в некоторых файлах используют `именно' такие кавычки, какое-то особое значение у них?
Спасибо.
Artem Chuprina
Jul 12, 2017, 1:40:03 PM7/12/17
to
fuf -> debian-...@lists.debian.org @ Wed, 12 Jul 2017 12:17:57 -0400:
> Салют всем!
> Взбесился "Xfce Terminal Emulator"(xfce4-terminal 0.6.3). Как только
> нажимаешь букву f открывается новая вкладка в окне терминала и немедленно
> переключается печать туда, причём не важно в середине слова или нет
> нажимаешь букву f! Через Menu>File> увидел, что Open Tab F! Я удалял и
> вновь поставил (xfce4-terminal 0.6.3) через Synaptic- не помогло.
Вряд ли эта операция удаляет пользовательские настройки оного. Я
полагаю, что если найти, где они хранятся, и на всякий случай прибить
все (мало ли что ЕЩЕ ты по нечанности там поменял...), то поможет.
Где они хранятся, описано, скорее всего, в его мане.
> Поставил Synaptic-ом "fbterm"-A fast framebuffer based terminal
> emulator for Linux, попробовал открыть его через Xterm и получил: ~$
> fbterm stdin isn't a interactive tty! ~$.
Логично. Он же для консоли. Для "настоящей", в смысле. Тоже
смешно. Совсем настоящей в линуксе не бывает. Но вот если не загрузить
иксы, то будет как раз то, где его имеет смысл использовать.
> Прямо не знаю что делать. Может Synaptic-ом ещё что нибудь поставить?
> Там даже gnome-terminal есть, но у меня Xfce, и не известно будет ли
> работать, а загружать предлагается много МВ. Это первое в чём прошу
> помочь и подсказать. ------------------ У моего Xterm мельчайший
> шрифт, как увеличить?
Для начала - Ctrl-RightButton и выбрать размер побольше. Но вообще
настраивать xterm — это надо выучить, что такое X resources. Сейчас
среди софта для Ю. Конечного это не модно, но xterm намного старше этой
немоды, он настраивается через них. Нет, гуй для выбора шрифта не
предусмотрен. Вернее, предусмотрен, но совершенно отдельной программой
:)
> И прошу разъяснить как вообще настраивать терминалы (цвет, шрифт, и
> т.п.), я уже обращался насчёт раскладки, спасибо помогли тогда.
> ------------------
Модные через меню настроек. Старые добрые (xterm, *rxvt) через
ресурсы. Консольные, если до них дело дойдет, совсем кто в лес, кто по
дрова, надо их маны читать.
> И не пойму почему в некоторых файлах используют `именно' такие
> кавычки, какое-то особое значение у них? Спасибо.
Когда как. Вообще-то в нормальной печати правая и левая кавычки
отличаются. (И кстати, применяются и одинарные, только я правил не
знаю.) Иногда в английской традиции люди их и при наборе текста
различают. Если они ограничены набором символов ASCII, ISO-8859-1, или
чего-то еще в том же духе, то получается вот так. А иногда это
машинночитаемый (или и-машинно-тоже-читаемый, как markdown или asciidoc)
формат. Машине тоже полезно знать, где у тебя начинается цитата, а где
заканчивается.
> Салют всем!
> Взбесился "Xfce Terminal Emulator"(xfce4-terminal 0.6.3). Как только
> нажимаешь букву f открывается новая вкладка в окне терминала и немедленно
> переключается печать туда, причём не важно в середине слова или нет
> нажимаешь букву f! Через Menu>File> увидел, что Open Tab F! Я удалял и
> вновь поставил (xfce4-terminal 0.6.3) через Synaptic- не помогло.
полагаю, что если найти, где они хранятся, и на всякий случай прибить
все (мало ли что ЕЩЕ ты по нечанности там поменял...), то поможет.
Где они хранятся, описано, скорее всего, в его мане.
> Поставил Synaptic-ом "fbterm"-A fast framebuffer based terminal
> emulator for Linux, попробовал открыть его через Xterm и получил: ~$
> fbterm stdin isn't a interactive tty! ~$.
смешно. Совсем настоящей в линуксе не бывает. Но вот если не загрузить
иксы, то будет как раз то, где его имеет смысл использовать.
> Прямо не знаю что делать. Может Synaptic-ом ещё что нибудь поставить?
> Там даже gnome-terminal есть, но у меня Xfce, и не известно будет ли
> работать, а загружать предлагается много МВ. Это первое в чём прошу
> помочь и подсказать. ------------------ У моего Xterm мельчайший
> шрифт, как увеличить?
настраивать xterm — это надо выучить, что такое X resources. Сейчас
среди софта для Ю. Конечного это не модно, но xterm намного старше этой
немоды, он настраивается через них. Нет, гуй для выбора шрифта не
предусмотрен. Вернее, предусмотрен, но совершенно отдельной программой
:)
> И прошу разъяснить как вообще настраивать терминалы (цвет, шрифт, и
> т.п.), я уже обращался насчёт раскладки, спасибо помогли тогда.
> ------------------
ресурсы. Консольные, если до них дело дойдет, совсем кто в лес, кто по
дрова, надо их маны читать.
> И не пойму почему в некоторых файлах используют `именно' такие
> кавычки, какое-то особое значение у них? Спасибо.
отличаются. (И кстати, применяются и одинарные, только я правил не
знаю.) Иногда в английской традиции люди их и при наборе текста
различают. Если они ограничены набором символов ASCII, ISO-8859-1, или
чего-то еще в том же духе, то получается вот так. А иногда это
машинночитаемый (или и-машинно-тоже-читаемый, как markdown или asciidoc)
формат. Машине тоже полезно знать, где у тебя начинается цитата, а где
заканчивается.
Igor Savlook
Jul 12, 2017, 2:10:02 PM7/12/17
to
включена настройка ребинда клавиш в меню. Просто пойди по пути
${HOME}/.config/xfce/terminal и убей там конфиги или просто
отредактируй accels.scm файл.
yuri.n...@gmail.com
Jul 12, 2017, 5:30:04 PM7/12/17
to
On Wed, 12 Jul 2017, fuf wrote:
> Прямо не знаю что делать. Может Synaptic-ом ещё что нибудь поставить? Там
> даже gnome-terminal есть, но у меня Xfce, и не известно будет ли работать,
> а загружать предлагается много МВ. Это первое в чём прошу помочь и
> подсказать.
Работать несомненно будет, но как вы правильно заметили, при
> Прямо не знаю что делать. Может Synaptic-ом ещё что нибудь поставить? Там
> даже gnome-terminal есть, но у меня Xfce, и не известно будет ли работать,
> а загружать предлагается много МВ. Это первое в чём прошу помочь и
> подсказать.
установке потянутся библиотеки из gnome (много МВ) и незаметно
так пол или четверть гнома поселятся вместе с Xfce.
Из легковесных, но с настройкой через меню, можно попробовать
lxterminal.
> ------------------
> У моего Xterm мельчайший шрифт, как увеличить? И прошу разъяснить как
> вообще настраивать терминалы (цвет, шрифт, и т.п.), я уже обращался насчёт
> раскладки, спасибо помогли тогда.
> ------------------
Ctrl и клике на 1-ю, 2-ю или 3-ю кнопку мыши.
Меню с шрифтами - Ctrl-Btn3.
Однако, выбор можно сделать только среди шрифтов которые
заботливо прописаны в X-resource.
Значения по умолчанию прописаны в /etc/X11/app-defaults/XTerm
и XTerm-color, а пользовательский файл с Х-русурсами
располагается в ~/.Xresources
Вот кусочек моего файла:
! Fonts: {{{2
! Note: size of fonts in points (pt) 1pt = 1inch/72
!--------------------------------------
! Xterm: {{{3
! test fonts: xterm -fa 'Font Name' -fs Size
! 18px = 9.19pt -> base
XTerm*faceName: Cousine
XTerm*faceSize: 9.19
XTerm*faceSize1: 4.60
XTerm*faceSize2: 6.12
XTerm*faceSize3: 7.15
XTerm*faceSize4: 8.17
XTerm*faceSize5: 10.2
XTerm*faceSize6: 11.2
XTerm*VT100.geometry: 80x25
Здесь используется ttf font Cousine из пакета fonts-croscore
Если добавить эти настройки в ~/.Xresources и выполнить
xrdb .Xresources
то при следующем запуске xterm они должны сработать.
Вообще, про xterm лучше тут вот почитать:
https://wiki.archlinux.org/index.php/Xterm
Ю.
fuf
Jul 12, 2017, 5:50:03 PM7/12/17
to
Жизнь налаживается! Сначала увеличил шрифт в Xterm по совету "Ctrl-RightButton", а потом опять-же по наущению в /home/user/.config/xfce4/terminal/accels.scm из строки (gtk_accel_path "<Actions>/terminal-window/new-tab" "f") убрал f, и всё исправилось. Спасибо! Но подскажите стоит ли учиться настраивать Xterm и т.п. вещам? Например очень хочется поставить "screen" (terminal multiplexer with VT100/ANSI terminal emulation), и чтобы шрифт цветной на разных окнах! Практическая польза от этих понтов может быть?, или это уже устарело?
Хотел уже отправить, но получил от yuri.nefedov то что надо, обязательно изучу, спасибо!
Хотел уже отправить, но получил от yuri.nefedov то что надо, обязательно изучу, спасибо!
Artem Chuprina
Jul 13, 2017, 12:40:03 AM7/13/17
to
fuf -> debian-...@lists.debian.org @ Wed, 12 Jul 2017 17:42:39 -0400:
> Жизнь налаживается! Сначала увеличил шрифт в Xterm по совету
> "Ctrl-RightButton", а потом опять-же по наущению в
> /home/user/.config/xfce4/terminal/accels.scm из строки (gtk_accel_path
> "<Actions>/terminal-window/new-tab" "f") убрал f, и всё исправилось.
> Спасибо! Но подскажите стоит ли учиться настраивать Xterm и т.п. вещам?
> Например очень хочется поставить "screen" (terminal multiplexer with
> VT100/ANSI terminal emulation), и чтобы шрифт цветной на разных окнах!
> Практическая польза от этих понтов может быть?, или это уже устарело?
Это не устарело, но скорее всего, Вам кажется, что screen делает не то,
что он делает на самом деле. screen - очень ценный зверь для работы на
_удаленной_ машине, в норме совершенно не нужный на _локальной_, если на
ней есть графическая среда.
> Жизнь налаживается! Сначала увеличил шрифт в Xterm по совету
> "Ctrl-RightButton", а потом опять-же по наущению в
> /home/user/.config/xfce4/terminal/accels.scm из строки (gtk_accel_path
> "<Actions>/terminal-window/new-tab" "f") убрал f, и всё исправилось.
> Спасибо! Но подскажите стоит ли учиться настраивать Xterm и т.п. вещам?
> Например очень хочется поставить "screen" (terminal multiplexer with
> VT100/ANSI terminal emulation), и чтобы шрифт цветной на разных окнах!
> Практическая польза от этих понтов может быть?, или это уже устарело?
что он делает на самом деле. screen - очень ценный зверь для работы на
_удаленной_ машине, в норме совершенно не нужный на _локальной_, если на
ней есть графическая среда.
Igor Savlook
Jul 13, 2017, 3:50:03 AM7/13/17
to
жить немогу.
Tim Sattarov
Jul 13, 2017, 1:30:03 PM7/13/17
to
On 13/07/17 03:40 AM, Igor Savlook wrote:
> Постоянно использую tmux на локальной машине с xfce. Вообще без него
> жить немогу.
Интересно послушать сценарий, когда это может пригодиться
> Постоянно использую tmux на локальной машине с xfce. Вообще без него
> жить немогу.
Igor Savlook
Jul 13, 2017, 2:30:03 PM7/13/17
to
On Thu, 2017-07-13 at 21:25 +0300, Sergey Matveev wrote:
> *** Tim Sattarov <sti...@gmail.com> [2017-07-13 21:20]:
> В терминале он предоставляет табы (tabs) и scrollback историю с
> поиском,
> плюс с удобными Vim клавишами навигации по ней -- можно использовать
> какой-нибудь простой терминал типа st (http://st.suckless.org/),
> множество буферов (а не один X11-овый), возможно заскриптовать запуск
> рабочего окружения (простым shell-скриптом задать как надо побить
> окна,
> именовать их, предварительно выполнить команды, итд). Я тоже не
> представляю жизни без tmux-а локально запускаемого ибо очень удобно.
>
Вот и я также.
> *** Tim Sattarov <sti...@gmail.com> [2017-07-13 21:20]:
> поиском,
> плюс с удобными Vim клавишами навигации по ней -- можно использовать
> какой-нибудь простой терминал типа st (http://st.suckless.org/),
> множество буферов (а не один X11-овый), возможно заскриптовать запуск
> рабочего окружения (простым shell-скриптом задать как надо побить
> окна,
> именовать их, предварительно выполнить команды, итд). Я тоже не
> представляю жизни без tmux-а локально запускаемого ибо очень удобно.
>
Вот и я также.
Igor Savlook
Jul 13, 2017, 2:30:03 PM7/13/17
to
чтобы не терять данные окошки и программы с какими работал, собсно для
разработки и просто для пары твойки копий mc очень даже.
Sergey Matveev
Jul 13, 2017, 2:30:03 PM7/13/17
to
*** Tim Sattarov <sti...@gmail.com> [2017-07-13 21:20]:
В терминале он предоставляет табы (tabs) и scrollback историю с поиском,
плюс с удобными Vim клавишами навигации по ней -- можно использовать
какой-нибудь простой терминал типа st (http://st.suckless.org/),
множество буферов (а не один X11-овый), возможно заскриптовать запуск
рабочего окружения (простым shell-скриптом задать как надо побить окна,
именовать их, предварительно выполнить команды, итд). Я тоже не
представляю жизни без tmux-а локально запускаемого ибо очень удобно.
--
плюс с удобными 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
yuri.n...@gmail.com
Jul 13, 2017, 3:00:02 PM7/13/17
to
вкладки в 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'
и вуаля...
Ю.
Victor Wagner
Jul 13, 2017, 3:40:03 PM7/13/17
to
On Thu, 13 Jul 2017 21:59:04 +0300 (MSK)
yuri.n...@gmail.com wrote:
>
> screen или tmux позволяют легко настраивать
> вкладки в xterm и работать с нужной конфигурацией.
А вот, кстати, не поделится ли кто опытом - как screen или tmux
yuri.n...@gmail.com wrote:
>
> screen или tmux позволяют легко настраивать
> вкладки в xterm и работать с нужной конфигурацией.
правильно сочетать с 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-а).
Alexander Galanin
Jul 13, 2017, 4:00:03 PM7/13/17
to
13.07.2017 22:34, Victor Wagner пишет:
места, способ есть: https://gist.github.com/martijnvermaat/8070533
> (похоже тут ничего не придумаешь кроме встраивания в мультиплексор
> терминалов своего agent-forwarder-а).
А правильного решения никто не делает и живут с почти никого не
стесняющим вышеописанным ограничением.
--
Alexander Galanin
> 2. Придумать способ как сделать, чтобы при реконнекте к screen-у у
> выполняющихся внутри его сессий процессов появлялся доступ к ssh-ключам
> той сессии, откуда выполнен реконнект.
В предположении, что пользователь одновременно работает только из одного
> выполняющихся внутри его сессий процессов появлялся доступ к ssh-ключам
> той сессии, откуда выполнен реконнект.
места, способ есть: https://gist.github.com/martijnvermaat/8070533
> (похоже тут ничего не придумаешь кроме встраивания в мультиплексор
> терминалов своего agent-forwarder-а).
стесняющим вышеописанным ограничением.
--
Alexander Galanin
Artem Chuprina
Jul 13, 2017, 4:20:02 PM7/13/17
to
Victor Wagner -> debian-...@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 не надо, я и не проверял.
> А вот, кстати, не поделится ли кто опытом - как 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 не надо, я и не проверял.
Jurgen V. Uzbekoff
Jul 14, 2017, 1:20:02 AM7/14/17
to
1. Есть несколько конкретных табов с конкретными задачами — переключаюсь в
нужный на автопилоте;
2. Очень полезен большой scrollback и поиск/копирование в нём;
3. В terminal-emulator есть и свои табы — их по числу постоянных удалённых
соединений, плюс один локальный; а в каждом из них свой набор
мультиплексированных терминалов (не совсем локальный сценарий, каюсь);
4. При необходимости можно подключиться удалённо и иметь привычное
окружение — пожалуй, самый труднореализуемый сценарий без использования
мультиплексора…
--
IOpuk.
Tim Sattarov
Jul 14, 2017, 12:10:04 PM7/14/17
to
On 14/07/17 01:15 AM, Jurgen V. Uzbekoff wrote:
> Свои пять копеек. Про screen, но не суть:
Привет ! давно тебя здесь не видел :)
> Свои пять копеек. Про screen, но не суть:
> 1. Есть несколько конкретных табов с конкретными задачами — переключаюсь в
> нужный на автопилоте;
> 2. Очень полезен большой scrollback и поиск/копирование в нём;
А разве в эмуляторе этого нет ? Зачем screen ?
> нужный на автопилоте;
> 2. Очень полезен большой scrollback и поиск/копирование в нём;
> 3. В terminal-emulator есть и свои табы — их по числу постоянных удалённых
> соединений, плюс один локальный; а в каждом из них свой набор
> мультиплексированных терминалов (не совсем локальный сценарий, каюсь);
я в своих скриптах, когда нужно заходить на машину(ы) за бастионом
> соединений, плюс один локальный; а в каждом из них свой набор
> мультиплексированных терминалов (не совсем локальный сценарий, каюсь);
(jump-server, bastion) открываю локальную сессию screen с подключением к
бастиону и подключением к остальным серверам из списка. Удобно да. Плюс
журналированине сессии в файл и портирование скрипта на другие платформы
становится немного легче.
Ну и стандартное использование: открыть screen для критичной/долгой
операции на удалённом сервере, "штоб не порвалось посередине"
Мой вопрос больше, про: какая разница
- запустить терминал с кучей вкладок и перейти в нужные папки/запустить
нужную программу
или
- запустить локальный screen/tmux всё с теми же программами ?
(это наверное подразумевает, графический терминал, в то же время
tmux/screen менее требовательны)
Sergey Matveev
Jul 14, 2017, 12:30:03 PM7/14/17
to
*** Tim Sattarov <sti...@gmail.com> [2017-07-14 19:10]:
А в каком-нибудь urxvt я не помню чтобы в буфере можно было искать
текст, перемещаться по нему vim-binding-ами.
>Мой вопрос больше, про: какая разница
>- запустить терминал с кучей вкладок и перейти в нужные папки/запустить
>нужную программу
>или
>- запустить локальный screen/tmux всё с теми же программами ?
Как автоматизировать запуск обычного GUI терминала и в нём ввести всякие
команды, открыть нужные табы, назвать их, итд? Это значит терминал
должен поддерживать какой-то API и его надо бы вызывать. Я даже не знаю
есть ли такое в них, но это будет terminal/vendor-lockin. А с
tmux/screen можно заменить эмулятор терминала не трогая автоматизацию с
terminal-specific API.
>> 2. Очень полезен большой scrollback и поиск/копирование в нём;
>А разве в эмуляторе этого нет ? Зачем screen ?
Ни того, ни другого нет например в st терминале (http://st.suckless.org/).
>А разве в эмуляторе этого нет ? Зачем screen ?
А в каком-нибудь urxvt я не помню чтобы в буфере можно было искать
текст, перемещаться по нему vim-binding-ами.
>Мой вопрос больше, про: какая разница
>- запустить терминал с кучей вкладок и перейти в нужные папки/запустить
>нужную программу
>или
>- запустить локальный screen/tmux всё с теми же программами ?
команды, открыть нужные табы, назвать их, итд? Это значит терминал
должен поддерживать какой-то API и его надо бы вызывать. Я даже не знаю
есть ли такое в них, но это будет terminal/vendor-lockin. А с
tmux/screen можно заменить эмулятор терминала не трогая автоматизацию с
terminal-specific API.
Igor Savlook
Jul 14, 2017, 1:50:03 PM7/14/17
to
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 от теминала и уйти гулять (особенно
> On 14/07/17 01:15 AM, Jurgen V. Uzbekoff wrote:
> > Свои пять копеек. Про screen, но не суть:
>
> Привет ! давно тебя здесь не видел :)
> > 1. Есть несколько конкретных табов с конкретными задачами —
> > переключаюсь в
> > нужный на автопилоте;
> > 2. Очень полезен большой scrollback и поиск/копирование в нём;
>
> А разве в эмуляторе этого нет ? Зачем screen ?
полезно на серверах хотя я юзаюи и на исках).
Ivan Shmakov
Jul 14, 2017, 4:20:03 PM7/14/17
to
>>>>> Artem Chuprina <r...@lasgalen.net> 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-а).
> Ко второму у меня есть. Правда, довольно навороченное.
[…]
(в частности: $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
>>>>> 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) "$@"
Откуда такая нелюбовь к содержащим пробелы именам файлов
> #!/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 /'
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
Ivan Shmakov
Jul 15, 2017, 1:30:04 AM7/15/17
to
>>>>> Sergey Matveev <star...@stargrave.org> writes:
>>>>> *** Tim Sattarov <sti...@gmail.com> [2017-07-14 19:10]:
>>> 2. Очень полезен большой scrollback и поиск/копирование в нём;
>> А разве в эмуляторе этого нет ? Зачем screen ?
> Ни того, ни другого нет например в st терминале
> (http://st.suckless.org/).
У suckless нет и много чего еще. Я был бы весьма за slock, если
>>>>> *** Tim Sattarov <sti...@gmail.com> [2017-07-14 19:10]:
>>> 2. Очень полезен большой scrollback и поиск/копирование в нём;
>> А разве в эмуляторе этого нет ? Зачем screen ?
> Ни того, ни другого нет например в st терминале
> (http://st.suckless.org/).
бы его можно было бы использовать вместе с Kerberos. Хотя,
подозреваю, i18n окажется даже более слабым местом.
> А в каком-нибудь urxvt я не помню чтобы в буфере можно было искать
> текст, перемещаться по нему vim-binding-ами.
Весьма удобно, между прочим, 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,
> Как автоматизировать запуск обычного GUI терминала и в нём ввести
> всякие команды, открыть нужные табы, назвать их, итд? Это значит
> терминал должен поддерживать какой-то API и его надо бы вызывать.
> Я даже не знаю есть ли такое в них, но это будет
> terminal/vendor-lockin. А с tmux/screen можно заменить эмулятор
> терминала не трогая автоматизацию с terminal-specific API.
вместе с соответствующим lock-in.
--
FSF associate member #7257 np. To Catch a Falling Star — Forest Rain
Ivan Shmakov
Jul 15, 2017, 5:00:02 AM7/15/17
to
>>>>> Ivan Shmakov <iv...@siamics.net> writes:
>>>>> Artem Chuprina <r...@lasgalen.net> 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
>>>>> Artem Chuprina <r...@lasgalen.net> 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?
--
FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Artem Chuprina
Jul 15, 2017, 8:00:03 AM7/15/17
to
Ivan Shmakov -> debian-...@lists.debian.org @ Sat, 15 Jul 2017 08:35:19 +0000:
>>> Собственно, в ~/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. Мало ли, кто их хочет...
>>> Собственно, в ~/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/, разумеется.
Ivan Shmakov
Jul 15, 2017, 9:10:03 AM7/15/17
to
>>>>> Artem Chuprina <r...@lasgalen.net> writes:
>>>>> Ivan Shmakov -> debian-russian@ @ Sat, 15 Jul 2017 08:35:19 +0000:
Я так думаю, что лишь у очень немногих программ действительно
найдется веская причина выяснять, а не по SSH ли их используют,
и если так, то где находится клиент?
Меня бы такое любопытство со стороны используемой мной программы
— насторожило.
FWIW,
$ grep -F -- SSH_ < .screenrc
unsetenv SSH_CLIENT
unsetenv SSH_CONNECTION
unsetenv SSH_TTY
$
>>>>> Ivan Shmakov -> debian-russian@ @ Sat, 15 Jul 2017 08:35:19 +0000:
найдется веская причина выяснять, а не по SSH ли их используют,
и если так, то где находится клиент?
Меня бы такое любопытство со стороны используемой мной программы
— насторожило.
FWIW,
$ grep -F -- SSH_ < .screenrc
unsetenv SSH_CLIENT
unsetenv SSH_CONNECTION
unsetenv SSH_TTY
$
Artem Chuprina
Jul 15, 2017, 12:00:02 PM7/15/17
to
Sergey Matveev -> debian-...@lists.debian.org @ Fri, 14 Jul 2017 19:21:01 +0300:
> *** Tim Sattarov <sti...@gmail.com> [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'ом, в
зависимости от того, удаленный хост или локальный...
> *** Tim Sattarov <sti...@gmail.com> [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.
screen — стандарт де-факто, и поддерживает его?
Чем, кстати, tmux лучше, чем screen?
Я, кстати, подумываю о том, чтобы у меня все-таки был единый
интерфейс. А то Ctrl-A то работает сразу, то управляет screen'ом, в
зависимости от того, удаленный хост или локальный...
Sergey Matveev
Jul 15, 2017, 12:30:02 PM7/15/17
to
*** Artem Chuprina <r...@lasgalen.net> [2017-07-15 18:59]:
жизнь я много терминалов сменил, а вот tmux не на что, ни разу.
>Чем, кстати, tmux лучше, чем screen?
Куда более удобной конфигурацией и скриптованием, хотя это наверное
субъективно. Существенно меньшими размерами (хотя в GNU screen больше
фич, типа работы с последовательными консолями). vi-like клавишами для
поиска. Судя по всему к screen нельзя подключиться несколькими клиентами
(несколько людей смотрят в одну сессию), а это killer-feature. Я так
точно и не понял, но есть ли в screen-е vertical pane разделение? Можно
ли в screen послать в любой pane какую-то последовательность клавиш,
что, опять же при скриптовании, очень удобно и гибко?
>Зато у тебя будет screen/tmux vendor lock-in. Или tmux счел, что API
>screen — стандарт де-факто, и поддерживает его?
Терминалов -- десятки видов, а GNU screen один и tmux один. За свою
>screen — стандарт де-факто, и поддерживает его?
жизнь я много терминалов сменил, а вот tmux не на что, ни разу.
>Чем, кстати, tmux лучше, чем screen?
субъективно. Существенно меньшими размерами (хотя в GNU screen больше
фич, типа работы с последовательными консолями). vi-like клавишами для
поиска. Судя по всему к screen нельзя подключиться несколькими клиентами
(несколько людей смотрят в одну сессию), а это killer-feature. Я так
точно и не понял, но есть ли в screen-е vertical pane разделение? Можно
ли в screen послать в любой pane какую-то последовательность клавиш,
что, опять же при скриптовании, очень удобно и гибко?
Ivan Shmakov
Jul 15, 2017, 1:30:03 PM7/15/17
to
>>>>> Sergey Matveev <star...@stargrave.org> writes:
>>>>> *** Artem Chuprina <r...@lasgalen.net> [2017-07-15 18:59]:
[…]
>>>>> *** Artem Chuprina <r...@lasgalen.net> [2017-07-15 18:59]:
>> Чем, кстати, tmux лучше, чем screen?
> Куда более удобной конфигурацией и скриптованием, хотя это наверное
> больше фич, типа работы с последовательными консолями). vi-like
> клавишами для поиска.
Конкретнее?
> клавишами для поиска.
> Судя по всему к screen нельзя подключиться несколькими клиентами
> (несколько людей смотрят в одну сессию), а это killer-feature.
…
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
> разделение?
‘C-a |’
(split -v)
Split the current region vertically into two new ones.
> Можно ли в screen послать в любой pane какую-то последовательность
> клавиш, что, опять же при скриптовании, очень удобно и гибко?
Sergey Matveev
Jul 15, 2017, 1:50:02 PM7/15/17
to
*** Ivan Shmakov <iv...@siamics.net> [2017-07-15 20:28]:
#!/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 всё это умеет, то тогда (не считая размера), вопрос вкуса
наверное.
> > Куда более удобной конфигурацией и скриптованием, хотя это наверное
> > субъективно. Существенно меньшими размерами (хотя в GNU Screen
> > больше фич, типа работы с последовательными консолями). vi-like
> > клавишами для поиска.
>
> Конкретнее?
Конкретнее что? Удобство? Вот один из скриптов, который неплохо читается.
> > субъективно. Существенно меньшими размерами (хотя в 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.
> > Я так точно и не понял, но есть ли в screen-е vertical pane
> > разделение?
Если screen всё это умеет, то тогда (не считая размера), вопрос вкуса
наверное.
Artem Chuprina
Jul 15, 2017, 2:20:02 PM7/15/17
to
Ivan Shmakov -> debian-...@lists.debian.org @ Fri, 14 Jul 2017 20:00:32 +0000:
>> 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. То, что написано у меня, я хотя бы прочесть
в состоянии...
>> 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"//\\\'/\\\'\\\\\\\'\\\'}\\\'
в состоянии...
Ivan Shmakov
Jul 15, 2017, 3:00:02 PM7/15/17
to
>>>>> Artem Chuprina <r...@lasgalen.net> writes:
>>>>> Ivan Shmakov -> debian-russian@ @ Fri, 14 Jul 2017 20:00:32 +0000:
[…]
>>> 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
--
>>>>> Ivan Shmakov -> debian-russian@ @ Fri, 14 Jul 2017 20:00:32 +0000:
[…]
>>> 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. То, что написано у меня, я хотя бы
> прочесть в состоянии...
обработке всех возможных имен файлов. Другими словами —
содержащих одинарные кавычки (всюду заменяемые на «'\''»):
$ 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
--
Tim Sattarov
Jul 15, 2017, 10:00:02 PM7/15/17
to
У меня тоже был вопрос про разницу в предпочтениях, я в своё время начал
пользоваться 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 это конечно сооблазнительно, а простые сочетания для поиска
в буфере есть у многих терминалов.
Всё сводится, на мой взгляд, к личным предпочтениям.
У меня давно назревал более общий вопрос про личные настройки, наверное
задам его отдельным тредом.
Спасибо
пользоваться screen и как то с tmux после не пошло...
On 15/07/17 01:47 PM, Sergey Matveev wrote:
> аналогично есть скрипты которые запускают рабочее окружение:
> postgresql, redis, переходят в директории, делают virtualenv (если
> python проект), бьют нужным образом окна и их именуют.
(Продолжаю мощные вбросы :) )
> Как автоматизировать запуск обычного GUI терминала и в нём ввести
> всякие команды, открыть нужные табы, назвать их, итд? Это значит
> терминал должен поддерживать какой-то API и его надо бы вызывать. Я
> даже не знаю есть ли такое в них, но это будет terminal/vendor-lockin.
> А с tmux/screen можно заменить эмулятор терминала не трогая
> автоматизацию с terminal-specific API.
с разными окнами
чтобы заполнить экран либо открыть рабочие сессии. Особого знания "API "
не нужно, простой man gnome-terminal или что там тогда было.
vim bindings это конечно сооблазнительно, а простые сочетания для поиска
в буфере есть у многих терминалов.
Всё сводится, на мой взгляд, к личным предпочтениям.
У меня давно назревал более общий вопрос про личные настройки, наверное
задам его отдельным тредом.
Спасибо
Ivan Shmakov
Jul 16, 2017, 2:30:03 AM7/16/17
to
>>>>> Sergey Matveev <star...@stargrave.org> writes:
>>>>> *** Ivan Shmakov <iv...@siamics.net> [2017-07-15 20:28]:
>>> Куда более удобной конфигурацией и скриптованием, хотя это наверное
>>> субъективно. Существенно меньшими размерами (хотя в GNU Screen
>>> больше фич, типа работы с последовательными консолями). vi-like
>>> клавишами для поиска.
>> Конкретнее?
> Конкретнее что?
Что понимается под «vi-like клавишами для поиска»? Поскольку
>>>>> *** Ivan Shmakov <iv...@siamics.net> [2017-07-15 20:28]:
>>> Куда более удобной конфигурацией и скриптованием, хотя это наверное
>>> субъективно. Существенно меньшими размерами (хотя в GNU Screen
>>> больше фич, типа работы с последовательными консолями). 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 -"
вводится $ 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
$
[…]
Sergey Matveev
Jul 16, 2017, 4:10:02 AM7/16/17
to
*** Tim Sattarov <sti...@gmail.com> [2017-07-16 04:59]:
сочетания клавиш и вообще подходы к конфигурации. А с tmux-ом вздохнул
спокойно. Но это личные предпочтения.
>На что только люди не идут, чтобы не пользоваться docker-compose
>(Продолжаю мощные вбросы :) )
Да уж, учитывая то, что я когда-то владел boycottdocker.org доменом :-)
>У меня тоже был вопрос про разницу в предпочтениях, я в своё время начал
>пользоваться screen и как то с tmux после не пошло...
Я когда-то пользовался screen, но всегда, мягко говоря, ненавидел все их
>пользоваться screen и как то с tmux после не пошло...
сочетания клавиш и вообще подходы к конфигурации. А с tmux-ом вздохнул
спокойно. Но это личные предпочтения.
>На что только люди не идут, чтобы не пользоваться docker-compose
>(Продолжаю мощные вбросы :) )
Sergey Matveev
Jul 16, 2017, 4:10:03 AM7/16/17
to
*** Ivan Shmakov <iv...@siamics.net> [2017-07-16 09:25]:
это уже скорее просто перемещение, а не поиск.
> Я так понимаю, здесь запускается окно с Shell, в которое затем
> вводится $ su -? Честно говоря, я обычно $ screen 10 su -, без
> каких-либо промежуточных интерпретаторов.
Плюс оно бъётся по pane-ам, переходит в директории. Когда-то я сразу и
mutt и mocp запускал.
>$ cat < setup-slogin.screen
Тут вроде всё выглядит так, что запускается только ровно одна команда? В
tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего? На
самом деле кроме "su -" ещё и его пароль вставляется (загруженный с
зашифрованного диска -- мол если диск подключен, то это уж точно
авторизованный пользователь).
> Что понимается под «vi-like клавишами для поиска»? Поскольку
> Screen вроде бы умеет как «наращиваемый» Emacs-like поиск
> (C-r, C-s), так и «традиционный» (/, ?). Равно как и hjkl.
В дополнении к "/", "?" ещё клавиши типа "%", "{", "}", "f", итд. Хотя
> Screen вроде бы умеет как «наращиваемый» Emacs-like поиск
> (C-r, C-s), так и «традиционный» (/, ?). Равно как и hjkl.
это уже скорее просто перемещение, а не поиск.
> Я так понимаю, здесь запускается окно с Shell, в которое затем
> вводится $ su -? Честно говоря, я обычно $ screen 10 su -, без
> каких-либо промежуточных интерпретаторов.
mutt и mocp запускал.
>$ cat < setup-slogin.screen
Тут вроде всё выглядит так, что запускается только ровно одна команда? В
tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего? На
самом деле кроме "su -" ещё и его пароль вставляется (загруженный с
зашифрованного диска -- мол если диск подключен, то это уж точно
авторизованный пользователь).
Sergey Matveev
Jul 16, 2017, 4:20:02 AM7/16/17
to
Опять же, не знаю как в 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 все эти хотелки требуют
прожорливых огромных монстров терминалов.
когда по нажатию сочетания клавиш, он мне во временный файл сохраняет
содержимое текущего 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 все эти хотелки требуют
прожорливых огромных монстров терминалов.
Ivan Shmakov
Jul 16, 2017, 4:50:02 AM7/16/17
to
>>>>> Sergey Matveev <star...@stargrave.org> writes:
>>>>> *** Ivan Shmakov <iv...@siamics.net> [2017-07-16 09:25]:
>> Что понимается под «vi-like клавишами для поиска»? Поскольку Screen
>> вроде бы умеет как «наращиваемый» Emacs-like поиск (C-r, C-s), так и
>> «традиционный» (/, ?). Равно как и hjkl.
> В дополнении к "/", "?" ещё клавиши типа "%", "{", "}", "f", итд.
> Хотя это уже скорее просто перемещение, а не поиск.
Команды перемещения у Screen, разумеется, тоже есть; Less-like,
>>>>> *** Ivan Shmakov <iv...@siamics.net> [2017-07-16 09:25]:
>> Что понимается под «vi-like клавишами для поиска»? Поскольку Screen
>> вроде бы умеет как «наращиваемый» Emacs-like поиск (C-r, C-s), так и
>> «традиционный» (/, ?). Равно как и hjkl.
> В дополнении к "/", "?" ещё клавиши типа "%", "{", "}", "f", итд.
> Хотя это уже скорее просто перемещение, а не поиск.
если угодно; % — в начало буфера; G — в конец; etc.
Мне не приходилось участвовать в разработке GNU Screen, но не
вижу причин считать, что предложения «добавить Vi-клавиш» будут
заведомо отвергнуты разработчиками. Разве что из соображений
«обратной совместимости».
>> Я так понимаю, здесь запускается окно с Shell, в которое затем
>> вводится $ su -? Честно говоря, я обычно $ screen 10 su -, без
>> каких-либо промежуточных интерпретаторов.
Не вижу препятствий для неинтерактивного использования 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 запускал.
>> $ cat < setup-slogin.screen
> Тут вроде всё выглядит так, что запускается только ровно одна
> команда?
«штатные» интерфейсы.
В общем случае, это кажется куда как более надежным. Мало ли о
чем запущенное приложение захочет спросить пользователя сразу
после запуска? SSH-клиент, например, может предупреждение о
возможном MitM выдать — и попросить подтвердить доступ. Или, в
отсутствие ключа у агента — пароль спросить.
> В tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего?
> На самом деле кроме "su -" ещё и его пароль вставляется (загруженный
> авторизованный пользователь).
… Любопытно, а умеет ли sudo(8) учитывать факт наличия
произвольных файлов при выполнении авторизации?
Sergey Matveev
Jul 16, 2017, 5:10:02 AM7/16/17
to
*** Ivan Shmakov <iv...@siamics.net> [2017-07-16 11:49]:
что-то добавлять или как-то улучшать GNU screen когда есть Tmux. Как
минимум я наслышан о качестве кода последнего, но не о качестве первого.
Ища информация по поводу screen vs tmux, постоянно натыкался на то что в
tmux-е раньше стало всё хорошо с Unicode-ом, итд, итд. Я не считаю
screen плохим, он имеет право на существование, но если есть выбор то
мой падёт не на него чисто потому-что многое субъективное не нравится.
> > Когда-то я сразу и mutt и mocp запускал.
> Это может составить какую-либо проблему для Screen?
Насколько понимаю, если запустить screen mutt, то после выхода из mutt-а
и screen завершит свою работу? Очень часто проще выйти из mutt чтобы
например зайти в default почтовый ящик. Поэтому тут нужно именно shell
запустить, а в нём как бы вызвать mutt команду, чтобы при выходе из неё
я снова попал в shell.
>chdir /foo
>screen -t foo 3
>[...]
Отчасти я согласен что это *потенциально* менее безопаснее -- но я
считаю что нечего запускать ПО которому не доверяете, от которого ждёте
такого подвоха. И когда речь заходит о "человеческом" удобстве, то тут
не всегда до безопасности. Я хочу *именно*, как вы выразились, имитации
интерактивности -- я хочу буквально заменить себя, причём меньшей болью.
Я согласен что многое можно заменить shell-скриптами, то если я вот
каждый раз когда занимаюсь проектом XXX делаю:
cd ~/work/xxx
venv
workon xxx
cat todo.txt
export PS="..."
то исключительно удобно вот как всё написано -- взять и обернуть в tmux
команды, без создания shell-скрипта который правильно включит
virtualenv-ы, выставит переменные окружения, итд.
> > В tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего?
> ? Это вопрос?
Не, это я нечаянно поставил вопросительный знак.
> > На самом деле кроме "su -" ещё и его пароль вставляется (загруженный
> > с зашифрованного диска — мол если диск подключен, то это уж точно
> > авторизованный пользователь).
>
> … Любопытно, а умеет ли sudo(8) учитывать факт наличия
> произвольных файлов при выполнении авторизации?
Хочу заметить что пароль вставляется "имитацией интерактивности" -- то
есть tmux туда пихает сам пароль, прочитанный из файла, дальше лупит enter.
> Команды перемещения у Screen, разумеется, тоже есть; Less-like,
> если угодно; % — в начало буфера; G — в конец; etc.
>
> Мне не приходилось участвовать в разработке GNU Screen, но не
> вижу причин считать, что предложения «добавить Vi-клавиш» будут
> заведомо отвергнуты разработчиками. Разве что из соображений
> «обратной совместимости».
Повторюсь: тут вопрос субъективный похоже. Я не вижу смысла (для себя)
> если угодно; % — в начало буфера; G — в конец; etc.
>
> Мне не приходилось участвовать в разработке GNU Screen, но не
> вижу причин считать, что предложения «добавить Vi-клавиш» будут
> заведомо отвергнуты разработчиками. Разве что из соображений
> «обратной совместимости».
что-то добавлять или как-то улучшать GNU screen когда есть Tmux. Как
минимум я наслышан о качестве кода последнего, но не о качестве первого.
Ища информация по поводу screen vs tmux, постоянно натыкался на то что в
tmux-е раньше стало всё хорошо с Unicode-ом, итд, итд. Я не считаю
screen плохим, он имеет право на существование, но если есть выбор то
мой падёт не на него чисто потому-что многое субъективное не нравится.
> > Когда-то я сразу и mutt и mocp запускал.
> Это может составить какую-либо проблему для Screen?
и screen завершит свою работу? Очень часто проще выйти из mutt чтобы
например зайти в default почтовый ящик. Поэтому тут нужно именно shell
запустить, а в нём как бы вызвать mutt команду, чтобы при выходе из неё
я снова попал в shell.
>chdir /foo
>screen -t foo 3
> Именно. Никакой «имитации интерактивности» — исключительно
> «штатные» интерфейсы.
>
> В общем случае, это кажется куда как более надежным. Мало ли о
> чем запущенное приложение захочет спросить пользователя сразу
> после запуска? SSH-клиент, например, может предупреждение о
> возможном MitM выдать — и попросить подтвердить доступ. Или, в
> отсутствие ключа у агента — пароль спросить.
Вот именно под этим я и подразумевал что tmux удобнее (субъективно).
> «штатные» интерфейсы.
>
> В общем случае, это кажется куда как более надежным. Мало ли о
> чем запущенное приложение захочет спросить пользователя сразу
> после запуска? SSH-клиент, например, может предупреждение о
> возможном MitM выдать — и попросить подтвердить доступ. Или, в
> отсутствие ключа у агента — пароль спросить.
Отчасти я согласен что это *потенциально* менее безопаснее -- но я
считаю что нечего запускать ПО которому не доверяете, от которого ждёте
такого подвоха. И когда речь заходит о "человеческом" удобстве, то тут
не всегда до безопасности. Я хочу *именно*, как вы выразились, имитации
интерактивности -- я хочу буквально заменить себя, причём меньшей болью.
Я согласен что многое можно заменить shell-скриптами, то если я вот
каждый раз когда занимаюсь проектом XXX делаю:
cd ~/work/xxx
venv
workon xxx
cat todo.txt
export PS="..."
то исключительно удобно вот как всё написано -- взять и обернуть в tmux
команды, без создания shell-скрипта который правильно включит
virtualenv-ы, выставит переменные окружения, итд.
> > В tmux-е я делаю именно вставку каких-либо символов/клавиш и прочего?
> ? Это вопрос?
> > На самом деле кроме "su -" ещё и его пароль вставляется (загруженный
> > с зашифрованного диска — мол если диск подключен, то это уж точно
> > авторизованный пользователь).
>
> … Любопытно, а умеет ли sudo(8) учитывать факт наличия
> произвольных файлов при выполнении авторизации?
есть tmux туда пихает сам пароль, прочитанный из файла, дальше лупит enter.
Ivan Shmakov
Jul 16, 2017, 11:10:02 AM7/16/17
to
>>>>> Sergey Matveev <star...@stargrave.org> writes:
>>>>> *** Ivan Shmakov <iv...@siamics.net> [2017-07-16 11:49]:
>> Команды перемещения у Screen, разумеется, тоже есть; Less-like, если
>> угодно; % — в начало буфера; G — в конец; etc.
>> Мне не приходилось участвовать в разработке GNU Screen, но не вижу
>> причин считать, что предложения «добавить Vi-клавиш» будут заведомо
>> отвергнуты разработчиками. Разве что из соображений «обратной
>> совместимости».
> Повторюсь: тут вопрос субъективный похоже. Я не вижу смысла (для
> себя) что-то добавлять или как-то улучшать GNU screen когда есть
> Tmux.
Не исключено, что кто-то из читающих рассылку заинтересуется.
>>>>> *** Ivan Shmakov <iv...@siamics.net> [2017-07-16 11:49]:
>> Команды перемещения у Screen, разумеется, тоже есть; Less-like, если
>> угодно; % — в начало буфера; G — в конец; etc.
>> Мне не приходилось участвовать в разработке GNU Screen, но не вижу
>> причин считать, что предложения «добавить Vi-клавиш» будут заведомо
>> отвергнуты разработчиками. Разве что из соображений «обратной
>> совместимости».
> Повторюсь: тут вопрос субъективный похоже. Я не вижу смысла (для
> себя) что-то добавлять или как-то улучшать GNU screen когда есть
> Tmux.
Вопрос подписчиков был ведь в том, чтобы сравнить Screen и Tmux?
Вот мы этим и занимаемся, не так ли? Сам я, единолично,
сравнить их не могу, коль скоро имею опыт использования лишь
одного, и ознакомление с другим не является для меня, на текущий
момент, приоритетной задачей.
> Как минимум я наслышан о качестве кода последнего, но не о качестве
> первого.
тридцатилетие. За такой срок в коде имеют свойство
накапливаться «особенности.» Если этому активно не
противодействовать, во всяком случае.
> Ища информация по поводу screen vs tmux, постоянно натыкался на то
> что в tmux-е раньше стало всё хорошо с Unicode-ом, итд, итд.
момент, IIRC, GNU Screen у меня с UTF-8 работал вполне
адекватно.
Впрочем, те же символы двойной ширины мне были без особой
надобности, так что…
[…]
> Насколько понимаю, если запустить screen mutt, то после выхода из
> mutt-а и screen завершит свою работу?
Mutt, то по завершению Mutt окно действительно будет закрыто.
Или станет «зомби» — в зависимости от настроек.
> Очень часто проще выйти из mutt чтобы например зайти в default
> почтовый ящик. Поэтому тут нужно именно shell запустить, а в нём как
> бы вызвать mutt команду, чтобы при выходе из неё я снова попал в
> shell.
$ 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 удобнее (субъективно).
также имеет команду (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="..."
> то исключительно удобно вот как всё написано — взять и обернуть в
> я вот каждый раз когда занимаюсь проектом XXX делаю:
> cd ~/work/xxx
> venv
> workon xxx
> cat todo.txt
> export PS="..."
> tmux команды, без создания shell-скрипта который правильно включит
> virtualenv-ы, выставит переменные окружения, итд.
Секунду. Разве «обернуть в tmux команды» не означает «создать
> virtualenv-ы, выставит переменные окружения, итд.
shell-скрипт» (с командами tmux)?
А если так, то в чем преимущество set-buffer + paste-buffer
перед, например, $ bash --rcfile=? (Предполагая, что
используется именно Bash. Думаю, иные реализации Shell
предоставляют схожие возможности.)
Я так подозреваю, не только мне сие любопытно.
[…]
>>> На самом деле кроме «su -» ещё и его пароль вставляется
>>> (загруженный с зашифрованного диска — мол если диск подключен, то
>>> это уж точно авторизованный пользователь).
>> … Любопытно, а умеет ли sudo(8) учитывать факт наличия произвольных
>> файлов при выполнении авторизации?
> то есть tmux туда пихает сам пароль, прочитанный из файла, дальше
> лупит enter.
/Цель/ работы данного кода, как я ее понял, — дать пользователю
> лупит enter.
root-доступ, если «подключен зашифрованный диск».
Я не вижу причины, по которой некий «шлюз привилегий» не может
проверить факт /наличия/ файла — и дать root-доступ без
необходимости ввода какого-либо пароля. (Или хранения оного.)
--
FSF associate member #7257 np. Bittersweet — Apocalyptica 3013 B6A0 230E 334A
Sergey Matveev
Jul 16, 2017, 11:30:02 AM7/16/17
to
*** Ivan Shmakov <iv...@siamics.net> [2017-07-16 18:04]:
Просто никогда такие "опасные" команды в 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 редакторе: не всегда "делать
правильно" эффективно по времени -- иногда надо делать менее эффективно,
но зато с меньшими усилиями, если что, если например макрос "испорчен",
то с нуля его повторить.
> Причем здесь доверие? Я уже привел один пример: $ ssh REMOTE
> может дать доступ к Shell на удаленной машине; а может —
> предупреждение о том, что ключ REMOTE не соответствует
> сохраненному в ~/.ssh/known_hosts. Ни stuff, ни set-buffer +
> paste-buffer адекватно эту ситуацию обработать, IIUC, не
> позволяют.
Тогда я не так понял что вы имели в виду прежде. Да, хороший пример.
> может дать доступ к Shell на удаленной машине; а может —
> предупреждение о том, что ключ REMOTE не соответствует
> сохраненному в ~/.ssh/known_hosts. Ни stuff, ни set-buffer +
> paste-buffer адекватно эту ситуацию обработать, IIUC, не
> позволяют.
Просто никогда такие "опасные" команды в tmux не автоматизировал.
> Еще одна возможная ситуация — «внезапное» изменение умолчаний.
надо аккуратно, читая changelog-и софта. Хотя по ним не всегда понятно
затронет ли оно "меня" или нет. В любом случае всё это настолько редкие
для меня ситуации, что о них даже не собираюсь думать.
> А если так, то в чем преимущество set-buffer + paste-buffer
> перед, например, $ bash --rcfile=? (Предполагая, что
> используется именно Bash. Думаю, иные реализации Shell
> предоставляют схожие возможности.)
интерпретатора. Если мне нужно открыть несколько окон (pane-ов в tmux) и
в каждом из них что-то сделать своё, не одинаковое для всех окон, то
тогда нужно написать несколько rc-файлов. Вместо ровно одного, где всё
сконсолидировано -- нужно иметь и скрипт с tmux/screen обёрткой и
отдельные rc-файлы. Да, можно их поместить и в один, который их сохранит
во временные файлы, натравливая на них shell, но... это уже не удобно,
это уже костыли. Мне надо думать как делать --rcfile, а мне хочется
просто ручные действия "заскриптовать".
> /Цель/ работы данного кода, как я ее понял, — дать пользователю
> root-доступ, если «подключен зашифрованный диск».
он введёт пустоту и su меня пошлёт. Просто ввести su и пароль -- мне не
надо никаких проверок.
> Я не вижу причины, по которой некий «шлюз привилегий» не может
> проверить факт /наличия/ файла — и дать root-доступ без
> необходимости ввода какого-либо пароля. (Или хранения оного.)
может ли он это сделать. Мне этого не надо -- мне надо просто повторить
мои ручные действия.
Есть разница между "делать всё правильно" и сделать всё очень быстро,
наколеночные макросы и простые скрипты которые экономят время, пускай
даже которые упадут или не сработают. Время настройки автоматически
запускаемого рабочего окружения с "правильными" подходами в виде
rc-файлов, проверок на ошибки и прочего существенно больше чем просто
сказать что надо интерактивно ввести. Если что-то пошло не так, то проще
поправить скрипт.
Тут точно так же как при работе в Vim редакторе: не всегда "делать
правильно" эффективно по времени -- иногда надо делать менее эффективно,
но зато с меньшими усилиями, если что, если например макрос "испорчен",
то с нуля его повторить.
Victor Wagner
Jul 16, 2017, 2:00:02 PM7/16/17
to
On Sun, 16 Jul 2017 18:24:27 +0300
Sergey Matveev <star...@stargrave.org> wrote:
> *** Ivan Shmakov <iv...@siamics.net> [2017-07-16 18:04]:
> > Причем здесь доверие? Я уже привел один пример: $ ssh REMOTE
> > может дать доступ к Shell на удаленной машине; а может —
> > предупреждение о том, что ключ REMOTE не соответствует
> > сохраненному в ~/.ssh/known_hosts. Ни stuff, ни set-buffer +
> > paste-buffer адекватно эту ситуацию обработать, IIUC, не
> > позволяют.
>
> Тогда я не так понял что вы имели в виду прежде. Да, хороший пример.
> Просто никогда такие "опасные" команды в tmux не автоматизировал.
>
Опасной может быть даже команда cd.
Sergey Matveev <star...@stargrave.org> wrote:
> *** Ivan Shmakov <iv...@siamics.net> [2017-07-16 18:04]:
> > Причем здесь доверие? Я уже привел один пример: $ ssh REMOTE
> > может дать доступ к Shell на удаленной машине; а может —
> > предупреждение о том, что ключ REMOTE не соответствует
> > сохраненному в ~/.ssh/known_hosts. Ни stuff, ни set-buffer +
> > paste-buffer адекватно эту ситуацию обработать, IIUC, не
> > позволяют.
>
> Тогда я не так понял что вы имели в виду прежде. Да, хороший пример.
> Просто никогда такие "опасные" команды в tmux не автоматизировал.
>
Когда-то давно один мой знакоймый налетел на такую ситуацию:
У него был некоторый скрипт, который перегенерировал некоторое дерево
каталогов. Скрипт начиланся с
cd something; rm -rf *
Вот это something было расположено в его $HOME и являлось симлинком на
каталог на втором физическом диске (не помню уж куда этот диск был
смонтирован. На /srv какой-нибудь). Скрипт запускался по крону.
И вот однажды этот большой диск немножко умер. Поскольку это был
сервер, на нем как могли переконфигуировали сервисы и подняли с одним
диском. Про этот скрипт, бывший частным делом одного из сотрудников
компании, который в офисе в момент неприятности не случился,
естественно забыли.
Скрипт запустился, перейти по висячему симлинку не смог и выполнил
rm -rf прямо в $HOME этого товарища.
Мораль - всегда проверяйте exit code команды cd, а лучше
в начале любого скрипта пишите set -e.
> Ну для меня это "болезнь" людей которые любят bleeding edge.
> Обновляться надо аккуратно, читая changelog-и софта. Хотя по ним не
> всегда понятно затронет ли оно "меня" или нет. В любом случае всё это
> настолько редкие для меня ситуации, что о них даже не собираюсь
> думать.
разбирайся, где оно поехало, а где нет.
> Есть разница между "делать всё правильно" и сделать всё очень быстро,
> наколеночные макросы и простые скрипты которые экономят время, пускай
> даже которые упадут или не сработают. Время настройки автоматически
не успев навредить.
Sergey Matveev
Jul 16, 2017, 2:20:02 PM7/16/17
to
*** Victor Wagner <vi...@wagner.pp.ru> [2017-07-16 21:00]:
не команда cd, а rm -rf, а дальше уже действительно аккуратная проверка
всего вокруг неё.
>Вот нужно делать даже наколеночные скрипты правильно. Чтобы они упали,
>не успев навредить.
Если речь про tmux и screen, то повторюсь: нужно думать что писать,
думать что автоматизируется путём интерактивного ввода. Не нужно делать
из мухи слона и страдать из-за тучи shell файлов. Не нужно делать то,
что может навредить. Если в tmux скриптах только cd, workon (virtualenv
для python), export, su, запуск mutt/mocp/cmus/dnetc/whatever -- они не
навредят, даже если что-то пошло не так. Не нужно сравнивать general
purpose скрипты, и особые простые для запуска сред в tmux.
>Опасной может быть даже команда cd.
>cd something; rm -rf *
>Мораль - всегда проверяйте exit code команды cd, а лучше
>в начале любого скрипта пишите set -e.
Если делать скрипт, то я всеми руками за set -e. Опасна в вашем примере
>в начале любого скрипта пишите set -e.
не команда cd, а rm -rf, а дальше уже действительно аккуратная проверка
всего вокруг неё.
>Вот нужно делать даже наколеночные скрипты правильно. Чтобы они упали,
>не успев навредить.
думать что автоматизируется путём интерактивного ввода. Не нужно делать
из мухи слона и страдать из-за тучи shell файлов. Не нужно делать то,
что может навредить. Если в tmux скриптах только cd, workon (virtualenv
для python), export, su, запуск mutt/mocp/cmus/dnetc/whatever -- они не
навредят, даже если что-то пошло не так. Не нужно сравнивать general
purpose скрипты, и особые простые для запуска сред в tmux.
Jurgen V. Uzbekoff
Jul 17, 2017, 2:40:03 AM7/17/17
to
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 обычно :)
> On 14/07/17 01:15 AM, Jurgen V. Uzbekoff wrote:
> > Свои пять копеек. Про screen, но не суть:
> Привет ! давно тебя здесь не видел :)
Тут за выходные умные люди столько всего написали хорошего, чем я никогда
даже и не думал пользоваться… Но ты спросил — я рассказываю про личный
опыт.
> > 1. Есть несколько конкретных табов с конкретными задачами — переключаюсь в
> > нужный на автопилоте;
> > 2. Очень полезен большой scrollback и поиск/копирование в нём;
> А разве в эмуляторе этого нет ? Зачем screen ?
сегодняшнего дня даже и не пытался искать). И то, что я не пытался искать
эту функцию не только в этом terminal-emulator, но и в других, в которых я
запускал screen, мне очень нравится — мне в любом эмуляторе было
достаточно привычного функционала screen.
> > 3. В terminal-emulator есть и свои табы — их по числу постоянных удалённых
> > соединений, плюс один локальный; а в каждом из них свой набор
> > мультиплексированных терминалов (не совсем локальный сценарий, каюсь);
> я в своих скриптах, когда нужно заходить на машину(ы) за бастионом
> (jump-server, bastion) открываю локальную сессию screen с подключением к
> бастиону и подключением к остальным серверам из списка. Удобно да. Плюс
> журналированине сессии в файл и портирование скрипта на другие платформы
> становится немного легче.
> Ну и стандартное использование: открыть screen для критичной/долгой
> операции на удалённом сервере, "штоб не порвалось посередине"
>
> Мой вопрос больше, про: какая разница
> - запустить терминал с кучей вкладок и перейти в нужные папки/запустить
> нужную программу
> или
> - запустить локальный screen/tmux всё с теми же программами ?
папки и запустили нужные программы. Кроме того, всё-таки, очень полезно
иметь возможность подключиться к этому набору откуда угодно и чувствовать
себя как дома :)
> (это наверное подразумевает, графический терминал, в то же время
> tmux/screen менее требовательны)
терминала не требуется практически ничего — он всего лишь должен иметь
возможность запустить screen.
--
IOpuk.
Tim Sattarov
Jul 17, 2017, 3:20:03 PM7/17/17
to
On 17/07/17 02:31 AM, Jurgen V. Uzbekoff wrote:
> Но ты спросил — я рассказываю про личный опыт.
Понял, буду больше спрашивать :)
> Но ты спросил — я рассказываю про личный опыт.
>> А разве в эмуляторе этого нет ? Зачем screen ?
> Может в каком-то эмуляторе это и есть. В моём текущем я не обнаружил (а до
> сегодняшнего дня даже и не пытался искать). И то, что я не пытался искать
> эту функцию не только в этом terminal-emulator, но и в других, в которых я
> запускал screen, мне очень нравится — мне в любом эмуляторе было
> достаточно привычного функционала screen.
у меня наверное проблема с быстрым переключением между сессиями: когда
> Может в каком-то эмуляторе это и есть. В моём текущем я не обнаружил (а до
> сегодняшнего дня даже и не пытался искать). И то, что я не пытался искать
> эту функцию не только в этом terminal-emulator, но и в других, в которых я
> запускал screen, мне очень нравится — мне в любом эмуляторе было
> достаточно привычного функционала screen.
вводить последовательность нажатий, для переключения между сессиями.
Против простого Alt-[1-9] в терминале
Кстати, посмотрел на tmux ещё раз - что мне нравится в нём, так это
статусная строка, не потеряешься, в screen иногда не понятно, в каком
уровень реальности я сейчас...
yuri.n...@gmail.com
Jul 17, 2017, 4:20:03 PM7/17/17
to
On Mon, 17 Jul 2017, Tim Sattarov wrote:
> у меня наверное проблема с быстрым переключением между сессиями: когда
> вводить последовательность нажатий, для переключения между сессиями.
> Против простого Alt-[1-9] в терминале
Можно переопределить в screenrc. Мне нравится
> у меня наверное проблема с быстрым переключением между сессиями: когда
> вводить последовательность нажатий, для переключения между сессиями.
> Против простого Alt-[1-9] в терминале
escape `` # use ` instesd of Cntr-A
обычно это клавиша перед регистром с числами
и переключение сессий получается простым: `0 `1 `2 и т.д.
Обратный апостроф (`) набирается двойным нажатием (``)
> Кстати, посмотрел на tmux ещё раз - что мне нравится в нём, так это
> статусная строка, не потеряешься, в 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}'
...
Ю.
Artem Chuprina
Jul 17, 2017, 4:30:04 PM7/17/17
to
Tim Sattarov -> debian-...@lists.debian.org @ Mon, 17 Jul 2017 15:16:56 -0400:
Мне казалось, что в screen ее тоже можно включить. Только она по
умолчанию выключена. Потому что дисплей на телефоне не резиновый... :)
умолчанию выключена. Потому что дисплей на телефоне не резиновый... :)
0 new messages