From: Sergey Matveev Date: Thu, 20 Mar 2025 08:59:42 +0000 (+0300) Subject: Вторая версия schwabrak X-Git-Url: http://www.git.stargrave.org/?a=commitdiff_plain;h=fe47d5bf2fa368840c2a97a175bd3194d9e91fc8;p=stargrave-blog.git Вторая версия 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 наверняка есть в каждом дистрибутиве. А если и нет, то собираются легко, без зависимостей. Но пока это всё выглядит куда удобнее для работы. ---