Вторая версия schwabrak

Год назад (42b3d1b739b5f0cef40f349cdc7044a785dc604a) писал о том, что
schwabrak (bd94115b066472316ea03e85d611f732785f8b7c) более менее активно
использовался мною и немного коллегами. Сейчас в одном репозитории с
задачами надо было причесать и поприводить их в порядок. Переименование
задач или смена иерархии директорий приводит к довольно муторному и
аккуратному исправлению символических ссылок. Получать информацию,
фильтровать её, без использования вспомогательных скриптов -- ну так
себе по простоте дело. Да, информация есть, можно всё сделать, но это не
тривиальные запросы в shell-е, почти всегда скрипты.

Вспомнил одну презентацию, но которую не могу найти в блоге (или не
упоминал о ней), где показывалось как "просто и легко" можно работать с
Bluetooth или чем-то подобным в GNU/Linux. Мол, вот у вас есть sysfs,
где в ряде директорий вы можете узнать о существовании тех или иных
устройств. Сделав echo такого-то значения в такой sysfs файл, вы сможете
сделать то или иное действие. И там относительно простая задача
превращалась в дюжину команд на shell, со сплошными циклами и хаками.
Тогда как эта же задача под Windows решалась единственным API вызовом
функи с несколькими аргументами.

Или вот распространённый suckless подход к IM-ам: делать per-user
директории, внутри них FIFO файлы in/out и ещё метаинформационные. Можно
ли это скриптовать? Конечно, да. Но работать без кучи дополнительных
обвязок уже проблематично. А хотелось бы иметь нечто, с чем более менее
можно бы было и вообще без дополнительного софта работать. В противном
случае это уже будет именно решение под конкретный framework/toolset.

Вторая итерация schwabrak у меня, как мне кажется, стала более
дружелюбной к пользователю и машине. Но она уже потребует recutils
утилиты. Вместо директории tags/ с символическими ссылками на файлы
меток, вместо deps/ с ссылками на зависимые задачи, вместо единичных
файлов на каждое key-value значение, я решил всё это сложить в один
"meta" файл в recfile формате.

    created: 2025-02-13 11:45:56
    ass: stargrave
    status: done
    milestone: v2
    dep: another-issue
    dep: yet-another-issue

По идее я захотел вообще всё сложить в одну базу данных в recfile. Но
разделить её на множество .rec-ов точно нужно: тогда на каждую задачу
git log-ом можно будет смотреть историю только чётко заданной одной, не
иметь конфликтов с другими. Плюс поля about/result я так и оставил в
отдельных файлах, чтобы удобнее было с ними работать в редакторе (внутри
recfile каждая строчка должна была бы иметь "+ " префикс). И написано
несколько утилит, которые просто генерируют большой recfile с
about/result полями на выходе. И предполагается что дальше нужно
использовать recutils. В них и производить фильтрацию, выборку, создание
отчётов, без дополнительных не тривиальных (z)shell скриптов.

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