Просто сделай это.
Предполагается, что локальные программы, выходные данные которых направляются в другую программу, обнаружат, что они не подключены ни к какому терминалу, поэтому они не могут использовать какие-либо цветовые коды (, которые различаются между терминалами, поэтому переменная среды TERM )].
И когда локальная программа ssh
передается в другую программу, и вы не передаете опции -tt
, она подавляет выделение "псевдо -терминала" и вместо этого использует конвейеры. См. также man ssh
.
Если бы ваш код выделял «псевдо -терминал» вместо использования конвейера для захвата вывода, вы бы заметили этот факт. В большинстве случаев требуемый код более неясен и длиннее, чем если бы вы использовали канал; в большинстве случаев вам не нужны (или, как вы говорите, нужны )дополнительные возможности PTY.
Предположим, вы на самом деле не используете ssh
, а вместо этого используете sshpass -p '${auth.password}' ssh
...
sshpass, согласно его man
странице, запускает ssh «в выделенном TTY, обманывая его, заставляя думать, что он получает пароль от интерактивного пользователя» (да, это еще один PTY ).
В этом случае вам потребуется снова отключить нормальное поведение терминала для внутреннего соединения SSH. т.е. используя ssh -T
(, а не ssh -t
, как в одном из коммитов кода! ).
Я думаю, что префикс TERM=dumb
также дает очень похожий эффект. Это что-то вроде работы -. ssh -T
избавляет от необходимости возиться с TERM. Но я тестировал TERM=dumb sshpass sh -c 'echo $TERM'
на своем компе, вроде проходит нормально, и может вам так проще.
Следующий вопрос :Почему ваше тестирование говорит вам, что это необходимо, когда ваш код также уже работает, чтобы установить TERM=dumb
, прежде чем вы запустите (внутреннюю команду )ssh
? Вы ожидаете, что ssh
уже унаследовал TERM=dumb
. Посмотрите на код для Jsch.Я думаю, что ваш setPtyType("dumb")
не будет иметь никакого эффекта, по той причине, что у вас нет вызова setPty(true)
.
Моему пониманию противоречит Ваше утверждение, что setPty(false)
"ломается", но Вы не говорите как.
Предложение взглянуть на клавиатуру с помощью xev привело меня к выявлению вероятной проблемы. В частности,
xmodmap -pm
показал, что mod5 был переполнен, где мои модификации были включены с картой по умолчанию (для раскладки клавиатуры xkb US )из:
mod4 Super_L (0x25), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
по сравнению с моей картой
mod4 Super_L (0x25), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 <OTHER_KEYS, inc. Hyper_R> ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
Итак, ISO _Level3 _Shift срабатывал по Hyper и поэтому не работал.
Правка. 2019 -11 -18. В основном работало исправление до Super, а затем использование разных номеров модов. Подробности см. здесь :https://github.com/bjohas/Ubuntu-keyboard-map-like-OS-X/blob/master/Hyper%20key.md
.