Pull to refresh

Comments 47

Я не совсем понял, о чем речь.

>>Некоторые программы, показывая содержимое, восстанавливают
>>экран до запуска приложения
Oк.

>> Идём в консоль linux (настоящую, Ctrl-Alt-F1), пробуем vim —
>>при выходе мы видим предыдущее содержимое на экране.
>>less… видим. nano… видим.
Ok

>>То есть linux (согласно console_codes) этого не поддерживает.
вот тут я запутался. Какой именнно эффект не поддерживается?

>>Простая проверка подверждает подозрения —
>>на всех виртуалках vcsa девственно чистый,
>>потому что у нас нет VGA-адаптера.

Проверил в виртуалке на KVM: cat /dev/vcsa*
получил семь консолей с приглашением login.
Проверил на xen:
cat: /dev/vcsa*: No such file or directory

>>Идём обратно в настоящий linux (консоль),
>>логинимся по ssh на любой сервер, запускам mc,
>>и, вуаля — not supported.
Опять не понял, что именно «not supported». Можно дать подробное описание эффекта, которого необходимо достичь? Я из статьи понял, что вам нужно восстановление экрана до запуска приложения? Но, если всё так, как вы описываете, почему в putty все отлично работает?

Спасибо.

console_codes (точнее, консоль линукса) не поддерживает secondary display. Как увидеть разницу: пойти в консоль, запустить mc, нажать Ctrl-O. Выйти из mc, из той же консоли подключиться по ssh к чему угодно, запустить mc, нажать ctrl-o, заметить разницу.

В putty работает, потому что путти реализует не linux, а xterm.
Как увидеть разницу: пойти в консоль, запустить mc, нажать Ctrl-O. Выйти из mc, из той же консоли подключиться по ssh к чему угодно, запустить mc, нажать ctrl-o, заметить разницу.

Эмм, никакой разницы. На удалённом хосте показывает TERM=linux, как и ожидалось, но ctrl-o работает. Debian Sid, mc 4.7.0.9-1
Пожалуйста, закройте ваш любимый X-server, и выйдите в консоль (которая Ctrl-Alt-F1). gnome-console, putty, xterm, rxvt, konsole и т.д. не годятся — нужно именно консоль линукса.
Либо вы после этого забыли подключиться по ssh (или, ещё вариант, запустили ssh не выйдя из mc).

Я выше цитировал код — на удалённой машине mc просто физически не сможет получить доступ к файлам /dev/vcsa* на локальной машине.
Я ничего не забыл и ещё раз проверил. Я понимаю ваше объяснение и цитаты из кода и именно поэтому написал о том, что я наблюдаю другой эффект.
Ну, значит у вас произошло мистическое чудо и программа работает не так, как написано в её исходных текстах.

К сожалению, на чудесах я не специализируюсь.
а, вижу, понял о чём речь.
Да, и ещё я не вижу чтобы запускался cons.saver (хотя сам бинарник в системе есть).
906 if (!xterm_flag && !console_flag && !use_subshell && !output_starts_shell) {
(gdb) p use_subshell
$4 = 1


Вот поэтому у меня мессадж и не выводится. Другой вопрос как же всё-таки панели прячутся…
Панели-то прячутся, но содержимое того, что было под панелями на экран не выводится по нажатию на ctrl-o, только чёрный экран.
Действительно! Теперь всё понятно, спасибо.
Ага, вот теперь понятно, еще раз спасибо.
У вас же ядра всё-равно не абы какие, что мешает малость пропатчить и добавить эти устройства?
У нас эти устройства есть. Но тут нужно понимать, что зен не эмулирует vga-адаптер, он предоставляет виртуальный последовательный порт.

Отсюда, кстати, и заморочки с необходимостью рендеринга esc-последовательностей за пределами машины. Если бы был VGA-адаптер, то мы бы мирно-тихо читали/писали картинку, рендерингом которой бы занимался линукс.

Т.к. последовательный порт, то говорить про «устройство с копией видеопамяти» в принципе не имеет смысла.
Так и не нужен VGA-адаптер. От устройства требуется предоставлять матрицу nxm, где лежат символы. Почему так проблемно прокинуть этот интерфейс до софтины в Dom0?
написать свое устройство для зена сложно. как минимум, это два модуля ядра.

Далее, передача этих данных между доменами тоже не слишком просто.

и главное — даже если я создам такое устройство, то его не признает mc. А единственный метод его обмануть — хакнуть major от vga. мягко говоря, не очень мудрое решение.
да, спвсибо, сейчас поправлю.
А почему для эмуляции терминала не использовать screen? Не получалось забрать «отрендерённый» вывод с браузером? Или ещё что-то?
screen нужно ещё декодить, раз (сам screen тоже рисует esc-кодами, так что это шило на мыло), во-вторых у него нет нормальной сериализации, в третьих проблема с подсовыванием/забиранием ввода-вывода, в четвёртых screen имеет свой собственный TERM, который пользователям бы пришлось настраивать вручную. Плюс проблема выключенных машин.

Геморроя не меньше, а гибкости существенно меньше.
Раз в шарите, расскажите как работает мышь в MC? Щелкнул — выделился файл.

Ну вообще как события мыши обрабатывается в локальной консоли, удаленной. Вы по-любому знаете.
Вообще проблема мыши в консолях и терминалах (особенно в TUI) до сих пор не имеет готового стандартного решения (причем ни в никсах ни даже в винде).
Поддержка мыши изначально есть в GUI-терминалах, и если МС запущен в окне графического терминала, то, на мышь он корректно реагирует.
Если я не ошибаюсь, то в GUI-терминалах можно даже эмулировать МУЛЬТИТАЧ.
Однако вменяемой поддержки мыши (а тем более мультитача) в TUI-терминалах я к сожалению не встречал.
Поэтому у меня даже была мысль написать свой собственный TUI-терминал с поддержкой мыши (в том числе мультитача) и спрайт-анимации.
UFO just landed and posted this here
Есть набор ESC-кодов, MC может послать терминалу сообщение «давай сюда мышь», в этом случае нажатия кнопок мыши передаются как ESC-коды.

Мы не делали, потому что тогда возможность копирования текста сломается.
Во-первых, в MC встроенное копирование текста там, где это нужно. Т.е. в редакторе эти кнопки-и-положения-мышки-как-ESC-коды как раз очень даже нужны.

Во-вторых, во всех известных мне терминалках это поведение «эскейпится» — если человеку нужно срочно именно покопировать какой-то текст с экрана из приложения, которое «захватило мышку» — можно зажать Shift и тогда мышка начинаешь работать традиционно — выделять кусок текста на экране и копировать его в primary selection.
> откуда её позаимствовали все последующие консольные клоны NC: Dos Navigator, Volkov Commander, Far Navigator Manager и т.д.
А в чем драматичность проблемы-то? Я так понимаю, что у вас один эмулятор терминала, для него вполне можно прописать банально, что он работает только с TERM=xterm и всё. Для чего может быть нужна поддержка TERM=linux — и, самое главное, чем вы тут хуже всех остальных эмуляторов терминалов, которые толком тоже с ней не работают?
>Я так понимаю, что у вас один эмулятор терминала, для него вполне можно прописать банально, что он работает только с TERM=xterm и всё
Это нужно будет объяснять каждому пользователю. Каждый пользователь должен будет вручную указывать $TERM.
Вообще у пользователя в теории может быть миллион других значений TERM — не смущает? Вот люди из-под BSD будут ходить с какими-нибудь TERM=con80x25 и точно так же огребать проблем, пока не настроят TERM.

TERM=linux — это вообще очень странная по нынешним временам штука. Подавляющее большинство ходят либо из TERM={xterm,rxvt,rxvt-unicode} (либо юниксовые терминалки, либо PuTTY), либо TERM={screen,screen.linux,screen.bsd} (который почти тот же xterm).
Эм… Этот терминал висит на виртуальном RS232 в виртуальном линуксе. Там точно TERM=linux.
>либо PuTTY
И рисуется в браузере. Зачем — можешь прочитать предыдущие посты.
Ребят, я, возможно, тупой, но я не понимаю, как из того, что терминал проходит свой транспортный путь через «RS232 в виртуальном линуксе» следует то, что TERM=linux. У меня вот AIX есть, который через Serial-over-IPMI (тоже своего рода виртуальный RS232) отдает свой терминал — и там TERM будет такой, каким его выставлю _я_, прийдя туда каким-нибудь эмулятором терминала. Собственно, TERM и задает обычно сам эмулятор терминала — запуская под себя на удаленном конце первое приложение, с которым будет общаться (login или shell ли), неким образом передается, какие переменные среды можно начиная с этого приложения выставить.
>запуская под себя на удаленном конце первое приложение
Тут ничего не запускается. Терминал работает, начиная с загрузки.
Там login есть? Думаю, что есть. Вот в нем и выставить, нет?
Кхм. login запускается инитом/*getty, не терминалом. И не такой уж факт, что он есть.
Если речь идет об init'е, то там будет вот такая строчка в inittab, так?

T0:23:respawn:/sbin/getty -L ttyS0 115200

И, внезапно, именно сюда, в getty и можно прописать getty -L ttyS0 115200 xterm, чтобы в этом терминале был именно TERM=xterm с самого начала.
>И, внезапно, именно сюда, в getty и можно прописать getty -L ttyS0 115200 xterm, чтобы в этом терминале был именно TERM=xterm с самого начала.
Влезть в *чужую* виртуальную машину, чтобы прописать это?
В нее так или иначе влезать, чтобы прописать эту строчку. По умолчанию оно практически во всех известных мне современных дистрибутивах отключено. Да и ставятся там скорее всего не дистрибутивы с нуля, а все-таки клонируются система из каких-то заранее заготовленных образов — в них и прописывают обычно такое.
Как ни странно, этот топик я читал, только вот назвать это «чистой установкой с нуля», извините, я не могу. Там так или иначе для каждого дистрибутива делается свой набор управляющих воздействий (которые, кстати, в этой статье и описаны — для preseed, для kickstart и для YaST). И в любом случае есть какая-то стадия донастройки системы заранее заготовленными скриптами.
А с существующими системами что делать?
А сейчас вы с ними что делаете? Каким образом добавляется вывод на сериальную консоль?
Штатное при установке. Инсталлеры тоже, кстати, на последовательный порт рисуют.
«Штатное при установке» — оно у всех немножко разное, и, боюсь, что если уж его брать — то там как раз у большинства будет стоять что-то вроде TERM=vt100, а не TERM=linux.
Sign up to leave a comment.