https://invisible-island.net/ncurses/announce.html #terminfo

Вышла #ncurses 6.3, а, значит, самое время рассказать про Тома #Хуйкин а(Thomas E. Dickey).

Его сайт, https://invisible-island.net/, я называю "кладбище OSS софта", или "мечта бутстрапера"(зависит от настроения). Там доживают свой век такие известные вам и популярные проекты, как:

https://invisible-island.net/byacc/byacc.html - без этой реализации yacc не обходится ни одна цепочка по bootstrap flex && bison, потому что byacc не содержит в себе .y/.l файлов, все написано на православной сишечке.

https://invisible-island.net/lynx/lynx.html - широко известный в узких кругах текстовый браузер Lynx(не путать с Links!)

https://invisible-island.net/xterm/xterm.html - да, xterm тоже его работа. Кстати, каждый раз, когда вы запускаете эмулятор терминала, то вы сталкиваетесь с его наследием. https://invisible-island.net/xterm/ctlseqs/ctlseqs.pdf - это Мекка и Медина разработчиков эмуляторов терминалов, xterm control sequences, которые реализуют virtual all известные эмуляторы терминала(кроме rxvt-unicode).

https://invisible-island.net/mawk/mawk.html - одна из трех(с двумя половинами) ныне существующих реализаций языка AWK - mawk, gawk(GNU awk), nawk(new awk, one true awk, наследник AWK), и две половинки - реализации из heirloom и busybox.

byacc, mawk - необходимые компоненты для бутстрапа системы(потому что для сборки gawk требуется и yacc, и awk, такие дела).

Чувак графоман. Нет, ГРАФОМАН. Он документирует вообще ВСЕ, что он делает с кодом. Читать его эпопеи - сплошное историческое наслаждение:

https://invisible-island.net/byacc/byacc.html - отсюда я, например, узнал, что byacc и bison написал один и тот же человек.
https://invisible-island.net/ncurses/ncurses.faq.html - FAQ по ncurses, включая историю про лицензию ncurses(https://invisible-island.net/ncurses/ncurses-license.html, о 50 страницах).
https://invisible-island.net/ncurses/ncurses-netbsd.html - сравнение его поделия с реализацией из netbsd, о 50 страницах.

автореферат - https://invisible-island.net/personal/paperstuff.html

Обновление до ncurses 6.3 мне принесло боль. Товарищу явно нечего делать, а что делает программист, когда ему делать нечего? Правильно, вылизывает #ball_lick свой код. Ну, это так кажется изнутри. А со стороны - какие-то бессмысленные телодвижения ради движения. ./configure ncurses содержит штук 50 бессмысленных опций. Я тут хотел пример, но не смог выбрать из 50 - настолько они пустяшные и ненужные. Благодаря этим 50 настройкам, ncurses известны тем, что все(абсолютно, я не исключение) дистрибутивы конфигурируют их совершенно разным, и не очень совместимым, образом. Поэтому код по автодетекту ncurses - это кромешный ад.

Вот, чуваку было нечего делать, и он добавил совершенно бессмысленные:

--with-pkg-config-libdir
    revised option uses the actual 
    search path from pkg-config or 
    pkgconf using the output from --debug.

Кому это вообще надо? С этой задачей справляется(just as planned) pkg-config, НЕ НАДО это трогать!

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

Короче, наш человек, like, респект, уважуха.

Галопом по Европам.

А вы знали, что можно писать не sed -e s///, а sed -e s|||? Я вот узнал всего полгода назад, и мне это уже сэкономило кучу нервов и сил на эскейпинге /. Наверняка это всем давно известно, и никому не интересно, но я вот не знал.

———
https://hacks.mozilla.org/2021/12/webassembly-and-back-again-fine-grained-sandboxing-in-firefox-95/

Мозилла начала делать какую-то очень странную вещь. Часть библиотек они компилируют не в исполняемый код, а в #WASM, и джитят во время работы. Это им дает возможность установить менее большую surface для особо опасного кода, и, типа, так безопаснее. Я имею сказать:

1) Норм тащить в проект 1000000 строк кода, чтобы обезопасить 10000? Впрочем, JIT для WASM и так и так бы был.

2) А почему бы не сделать на WASM весь браузер? https://pbs.twimg.com/media/ELxt9LSXUAMlmIp.jpg А, было же такое - https://en.wikipedia.org/wiki/HotJava , не полетело.

———
https://codeberg.org/dnkl/foot/pulls/461 #foot
https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/2

#terminfo

Я тут пару раз писал про разные эмуляторы терминала, и сокрушался, что их авторы не хотят реализовывать нормальный протокол для tear-free rendering. Потом я написал, что, оказывается, разработчики терминалов в курсе этой проблемы, и даже изобрели syncronized updates, но почему-то все равно не хотят реализовывать правильный протокол. Я еще раз перечитал доступные тексты, и понял, что разработчики терминалов считают проблему решенной - кому надо(я, например), могут использовать syncronized updates, а проблемы негров(ncurses, например) шерифа не волнуют.

Пока читал, выяснил, что эти прекрасные люди не смогли договориться до одного варианта, и придумали аж целых два. Я оба и реализовал: #kitty #foot

https://github.com/pg83/ted/commit/a0aa84567efb7ac0760fde048dae0acf805fd188

В ncurses, наверное, не появится никогда.

https://codeberg.org/dnkl/foot/src/tag/1.11.0/README.md#user-content-xtgettcap #terminfo

Хорошая же тема, да, чтобы эмулятор терминала сразу отдавал свои capabilities, без всяких terminfo database, да?

Как бы это сделал вменяемый разработчик? Например, чтобы эта функция терминала отдавала TERMINFO запись as is, чтобы ее можно было там передать в curses, и использовать сразу? В крайнем случае, машинно-понимаемой трансляцией в json/xml/yaml.

Но, очевидно, Том #Хуйкин(разработчик xterm), индус #Ковид(разработчик Kitty), и неизвестный мне разработчик #foot(ссылку на опус которого про поддержку sync updates я тоже кидал), к такому решению, конечно, прийти не могли - это ж всего 3 строчки кода, и победную реляцию не напишешь!

Поэтому, конечно, все это сериализуется в промежуточный непонятный формат(с потерей в процессе), а клиенты потом должны восстанавливать. Зато можно будет написать еще 10 победных реляций про очередную перемогу в стиле "а мы поддержали еще 5 полей из terminfo"(несовместимым, конечно, образом).

———
https://www.opennet.ru/opennews/art.shtml?num=56703
https://www.opennet.ru/opennews/art.shtml?num=56704
https://www.opennet.ru/opennews/art.shtml?num=56700
https://www.opennet.ru/opennews/art.shtml?num=56699

Слушайте, вот вы понимаете, зачем люди клепают эти производные Debian с нескучными обоями? Меня, как автора настоящего, интересного, дистрибутива, это все, конечно, напрягает.

———
https://lobste.rs/s/adr60v/single_binary_executable_packages

Очередной срачик static vs. dynamic. Автор, конечно, говорит дельную вещь - а давайте, типа, сразу все приложения готовить в виде одного исполняемого файла, но он, наверное, сам так не пробовал, и не понимает, в чем проблема такого подхода.

https://www.opennet.ru/opennews/art.shtml?num=57194

Любли читать такие тексты. Самое интересное, конечно, не что там с wayland с nvidia, а "как оно вообще бывает, и какие задачи люди решают".

У меня выкристаллизировалась такая мысль - wayland сейчас находится примерно рядом с эмуляторами терминала. #foot, #alacritty, #kitty, #wayland #terminfo

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

А сообщение программе про изменение размера терминала до сих пор идет через SIGWINCH(== dbus рядом с wayland, если вы понимаете, о чем я), а не in-band в потоке сообщений. Про проблемы этого подхода я рассказывал. https://ru.wikipedia.org/wiki/SIGWINCH

Удивительный факт - GNOME, такое ощущение, ненавидит wayland, и, была бы их воля, они бы все переделали поверх dbus. Я этого совершенно не понимаю, они стояли у его истоков.

Возможно, я тут упустил какую-то интересную часть истории, расскажите.

———
Я решил устроить фичекат в своей пакетной базе. #mix

Как-то писал, что хочу, чтобы из моей пакетной базы можно было собирать как статически слинкованные программы, так и динамически слинкованные.

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

Смотрите.

Довольно часто рядом с библиотекой лежат какие-то данные.

В случае динамической линковки очень естественно, когда .so лежит рядом с данными для этой .so. Ну, типа, если уж слинковал это либу, то и данные понадобятся.

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

Поэтому я разделяю пакеты не только на bin, lib(помните, рассказывал про bin, lib контексты сборки?), но еще и на aux контекст(там лежит etc/, share/, etc). Программы и библиотеки уже собираются с путями, которые указывают в этот отдельный, третий, таргет. В сборе это выглядит примерно так - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/fontconfig/mix.sh#L14

Это будет выглядеть весьма криво в случае сборки .so файлов.

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

Короче, я пока решил это дело пофичекатить.

https://github.com/hanslub42/rlwrap #terminfo

Релиз ничем не примечателен, кроме того замечательного факта, что он у меня сегфолтится.

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

TL;DR - она добавляет readline в любую внешнюю программу, которая ориентирована на построчный ввод. С автодополнением, и прочими ништяками.

Конечно, было бы правильно, если бы этим занимался ваш терминал.

Ну, реально, если бы API терминала был чуть менее асинхронным, и можно было бы сделать синхронный вызов в него. Пишешь в него специальную ESC последовательность, а он тебе - строку с результатом в твой stdin.

Сразу исчезли бы все проблемы с лицензией на GNU readline, и она стала бы доступна по клиент-серверной модели всем желающим.

Вряд ли, конечно, господа терминало-писатели до этого договорятся. #foot

У меня тут одна зависимость потребовала новую(для меня!) библиотеку - https://github.com/HowardHinnant/date

Пока я чинил ее работоспособность в #stal/ix - https://github.com/pg83/ix/blob/main/pkgs/lib/date/ix/ix.sh (поменял пути, и добавил поддержку TZ env variable), задумался вот на какую тему.

Современные библиотеки не стесняются с тем, чтобы распарсить какие-нибудь arcane данные, доставшиеся в наследство от libc и прочих, не очень качественных, по современным стандартам, библиотек.

Ну, вот, реально - я знаю библиотеки, которые:

* парсят #terminfo database от ncurses
* парсят таймзоны
* умеют перетрахивать формат от gettext
* где-то я видел код, который напрямую работает с базой данных от libmagic, но, с ходу, не нашел
* системное хранилище сертификатов

Еще лет 5 - 7 назад это было как-то не принято - ты или готовил эти данные сам, или трахался с вызовом libc через ffi.

Я это связываю с появлением rust и go(видимо, java не смогла создать необходимое давление), где звать libc(и прочий шлак) в какой-то момент стало моветоном, люди разобрались в этом мусоре, и научились парсить его сами.

Это, конечно, хорошо, потому что тот же API в c для работы с таймзонами - это шлак, да и API ncurses - тоже.

https://dgl.cx/2023/09/ansi-terminal-security #foot #terminfo

Исчерпывающий текст про эмуляторы терминала, про то, что, по сути, они являются shell (в том смысле, в котором браузер является shell, то есть, sandbox для выполнения пользовательского кода, возможно, зловредного).

Про всякие ошибки, которые автор находил в разным там терминалах (спойлер - почти во всех), про связанные CVE, и про то, как правильно.

И, сюрпрайз-сюрпрайз, новый релиз xterm:

https://invisible-island.net/xterm/xterm.log.html

Patch #388 - 2023/10/22
improve disallowPasteControls by adding a category for the special characters known to stty (prompted by discussion with David Leadbeater).

А вот "David Leadbeater" - это как раз автор предыдущей статьи.

Совпадение?

https://twoot.site/@bean/113056942625234032

Хороший текст про #terminfo database.

Я несколько раз писал на эту тему, собрал все под тегом #terminfo, из этих текстов вы можете узнать:

* что человек, который поддерживает #terminfo, сошел с ума.

* что эмулятор терминала - это такой shell, по типу браузера.

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

* что разумный человек просто остановится на том, что умеет xterm, и не будет связываться ни с #terminfo, ни с #ncurses, и прочими расширениями от этих безумцев.

Вообще, главная мысль - что capabilities эмулятора терминала должен возвращать этот эмулятор, по запросу программы (которые, кстати, сами по себе - примитивный синхронный RPC), а вот все эти ncurses и terminfo должны умереть в страшных муках.