Терминал в виде чат-мессенджера: ересть или удобство?

ересь или удобство?

Для эмулятора - удобство. А по сути это всё равно будет надстройка над tty. Либо какой-то новомодный shell.

Надо будет попробовать написать…

Новомодным шеллом не обойтись, ведь в stdout/stderr валится всё кучей, и распарсить где чей выхлоп просто невозможно.

А с надстройкой над tty будет не так уж стрёмно, вон, тем же tmux все пользуются и не ноют.

Идея нравится, было бы интересно таким попользоваться

Теоретически – элементарно, и даже скорее всего более-менее совместимо с vt100, ибо потоки и так разделены на in/out/err.

«Ересь, но такая милая!»

Поддерживаю идею, особенно если команды пользователя будут отображаться справа.

ересть или удобство?

Да.

Мне нравится идея. С удовольствием попробовал бы.

Псевдографические (nano, mc, top) приложения не будут работать.

Таки приложения могут просто временно переключать окно в специальный режим или создавать новое окно/вкладку.

Есть ли такие терминальные программы для GNU/Linux? Пробовали? Как впечатления?

Подобные элементы есть в IPython console (как в текстовой, так и в той что на Qt), а также в блокнотах Jupyter. Последний можно использовать для разных интерпретаторов, в том числе для shell.

Многострочный ввод становится очень простым

только не забудьте оставить поддержку интерактивных программ, которые сами захватывают нажатия клавиш как только они нажаты, а не «построчный режим»

Можешь попробовать запилить такое. Не знаю, насколько будет удобно и скольким понравится, но вон в комментариях даже желающие попробовать есть.
На мой взгляд по 1 пункту не очень актуально, так как такие команды не часто используются. По остальным пунктам возможно было бы полезным.
По псевдографике п.1 мне кажется, что можно будет обыграть этот момент и переключаться, так как, например, все вышеперечисленные приложения меняют заголовок терминала (т.е. экспортируют переменную).
По удобству отдельного ввода и вывода зависит от задач, подобный принцип, например, использовался в cutecom, но там никак нельзя было передать например сочетаня клавиш, например C-k (ну или я не нашел как это сделать).

Думаю что удобно. Приходила такая мыль в голову много лет назад, мысль разбилась о то что непоятно как подружить это с существующими фичами механизма автодополнений (хотелось прежде всего дополнить эти самые механизмы автодополнения возможностями редактирования в стандартном поле ввода gui-toolkit, то же выделение ctrl-shift-стрелки и т.п.)

Возможно простейший вариант для начала - 2 отдельных эмулятора терминала. Процесс ввода команды shell направлятся на один из них, всё остальное на другой.

Я за, давно пора. Можно будет нормально редактировать строку с текущей командой, вставлять переносы строк. Не будут нужны инопланетные сочетания клавиш вроде Ctrl+A/E/F/B.

Подобные элементы есть в IPython console (как в текстовой, так и в той что на Qt)

Да, видел ipython не так давно в видео на ютубе, там был многострочный ввод кусков скрипта на питоне. Вот я и подумал, что жаль что такого нет для других языков.

Теоретически – элементарно, и даже скорее всего более-менее совместимо с vt100

Не, с VT100 это никак не совместимо, поскольку команды VT100 предполагают произвольное управление курсором, а в моей идее программа может только посылать сообщения.

Например, если использовать bash, то придётся его как-то изменить что бы он запускался в неинтерактивном режиме, а автодополнения все будут выполняться не самим башем, а терминалом.

потоки и так разделены на in/out/err

Запусти make -j16 и попробуй определить кому принадлежит определённая строка. ☺

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

поскольку команды VT100 предполагают произвольное управление курсором, а в моей идее программа может только посылать сообщения

Ну так и пусть «управление курсором» редактирует сообщение. Программы которые работают с терминалом умеют определять наличие терминала, а не просто stdout. Т.е. можно сделать запуск на выбор в терминальном режиме с редактированием сообщения, или в сыром stdout с добавлением сообщений.

Ну а в целом я сейчас подумал, и это не кажется особо удобным. Если ты запускаешь несколько команд, то вывод будет чередоваться, что не есть хорошо. Классический screen/tmux всё таки удобнее.

Ничего не мешает разные программы запускать в разных вкладках, как сообщения в ростере чат-программы.

Для этого уже есть мультиплексоры. И да, они могут быть в разных вкладках )

Для этого уже есть мульиплексоры. И да, они могут быт ьв разных вкладках )

Главная идея — это разделение автодополнения и прочего управления вводом и обрабатывающей программы.

Кстати это больше соответствует духу UNIX-way. Например bash только выполняет команды и всё, а формирует их (включая подсветку синтаксиса, многострочный ввод и прочее) другая программа.

запускать в разных вкладках

Это и так есть. В чём новизна?

Кстати это больше соответствует духу UNIX-way. Например bash только выполняет команды и всё, а формирует их (включая подсветку синтаксиса, многострочный ввод и прочее) другая программа.

Ну, как сказать. Например, дополнение неразрывно связанно с текущим состоянием оболочки и требует знание её состояния (разбор строки, набор функций, алиасов, значения переменных окружения и т.д.).

А тут ты прав, да. Придётся или жертвовать частью автодополнения (шелл-функции, переменные), или как-то это компенсировать, например системе дополнения придётся при запуске сессии запрашивать команды env и может ещё какие-то, а затем при подсветке синтаксиса следить. Но тогда дополнять некоторые шелл-функции и переменные, оно не сможет:

. <(base64 -d<<<ZXhwb3J0ICJzdXg9V2luZG93cyIK)

Почему подобное не используется в интерфейсе с компьютером?

Потому что терминал - это не то же самое, что твоя графическая консолька со спецэффектами.

Конечно, в 2020-м году это уже стало протухшим legacy, однако суть терминала - это вывод на экран символа принятого по проводку Rx, и отправка нажатого символа в проводок Tx.

Кроме псевдографики тут полно других недостатков. Например скрипты с частым интерактивным вводом, к примеру fsck в режиме восстанновления. Надоест головой двигать. Например проги где ввод совмещен с выводом by design, MySQL тащемта.

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

Новомодным шеллом не обойтись, ведь в stdout/stderr валится всё кучей, и распарсить где чей выхлоп просто невозможно.

Ничего что у каждого процесса свой stdout/stderr?

Зависит от make. В нормальном make:

% cat Makefile 
all: a b

a:
	echo a

b:
	echo b
% make -j 2   
--- a ---
echo a
a
--- b ---
echo b
b

интересно видеть человека, ниразу не пользовавшегося пайпами.

Это понятно, вот только они все срут в один tty/pts.

 % noisy-prog-1 --debug --verbose &
shit from 1
shit from 1
 % noisy-prog-2 --debug --verbose &
shit from 1
shit from 2
shit from 2
shit from 1
shit from 2
shit from shit

Берешь Emacs в двухпанельном режиме, в одной стороне код, в другой интерпретатор.

Выделив кусок текста из левого буфера его можно отправить на выполнение. А можно отдельно дополнительно подебажить runtime справа, не меняя кода.

Очень удобно работать так например с Maxima. Гораздо удобнее чем в стандартном интерфейсе Mathematica/Maple.

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

Конечно, в 2020-м году это уже стало протухшим legacy, однако суть терминала - это вывод на экран символа принятого по проводку Rx, и отправка нажатого символа в проводок Tx.

Ну вот моя идея как раз это и отражает. Пока ты набираешь — ничего не отправляется. Нажимаешь энтер — всё льётся в Tx, а то что получается по Rx копится и твоим нажатием энтера делится, сверху то что до, снизу то что во время или после.

и шелл который эти процессы запустил имеет над ними полный контроль

…поэтому терминал весь этот выхлоп различать не может.

[scheduler вошёл в чат]
scheduler:Таааак! Привет жиробасы!!!
javavm: я не толстая - у меня стэк широкий
сhromium: это всё чёртовы фронтендщики, так-то я легковесный
firefox:....
[scheduler потыкал firefox палкой]
firefox:....
[scheduler kicked firefox]

Терминалу это не надо различать. В терминал, если шелл это захочет, оно пойдёт только через шелл, а шелл оформит вывод так как ему надо. Так понятнее?

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

Сабж и должен быть шеллом вообще-то. Терминал трогать вообще не нужно.

Как раз нет. Нужен режим работы для всяких tui (ncurses/slang), иначе упрёшься в проблему №1, описанную топикстартером. Шелл об этом всём не знает и знать в принципе не должен.

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

Во всех нормальных мессенджерак хстати именно поэтому эти поля не разделены. А вот сделать align ответов к правой стороне было бы можно.

Так это и не проблема - для tui нужно мультиплексирование терминалов, а для это уже есть tmux. А вот шелл, который команды запускает по умолчанию в фоне, а их вывод асинхронно появляется в индивидуальных пузырях, это очень интересная идея.

Ну вот моя идея как раз это и отражает. Пока ты набираешь — ничего не отправляется. Нажимаешь энтер — всё льётся в Tx, а то что получается по Rx копится и твоим нажатием энтера делится, сверху то что до, снизу то что во время или после.

Это если пользоваться этим сугубо как шеллом. То есть «команда -> результат команды», но есть еще много нештатных ситуаций.

Например такое:

for i in `seq 1 10`;do echo -ne "$i\r";sleep 1;done

Справишсо ?

Ересь. Лучше бы чатик был без разделения области ввода и вывода.

А если располагать вертикально не будет понятно на какую команду пришел какой ответ.

Почему не будет?

(01:01:42) user@host:/$ ls
(01:01:42) /bin/ls (status 0):
 /bin /boot /home /root /usr /var /tmp
(01:01:47) user@host:/$ mkdir /boot
(01:01:47) /bin/mkdir (status 0)

Примерно так будет выглядеть, например. У mkdir пустой вывод, поэтому нет :. А набор команды до того как отправить на исполнение в отдельной форме снизу. Кстати удобно ещё тем, что можно набирать новую команду, прокрутив терминал вверх и подглядывая на вывод команды несколько экранов назад. Тогда как в классическом решении, когда набираешь команду, прямо над ней видишь в обязательном порядке вывод последней команды.

for i in `seq 1 10`;do echo -ne «$i\r»;sleep 1;done

Ну почему бы и нет:

(01:01:42) user@host:/$ for i in `seq 1 10`;do echo -ne "$i\r";sleep 1;done
(01:01:45) /bin/bash (status ?):
3

При этом 3 меняется пока вывод не завершится, например, в это время окно набора следующей команды активно, но она не отправляется пока предыдущая команда не завершит выполнение, в это время например status сменится с ? на 0 и время в предпоследней строке перестанет увеличиваться. Такое состояние «команду можно редактировать, но нельзя послать на исполнение» кстати в чатах бывает, когда например интернет пропадает.

То же самое можно и без \r.

А вообще это всё относится к пункту о полноэкранных приложениях. Но тут можно просто, как предлагали, сообщение терминала сделать редактируемым, пока из полноэкранного приложения не выйдут.