From fe47d5bf2fa368840c2a97a175bd3194d9e91fc8 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Thu, 20 Mar 2025 11:59:42 +0300 Subject: [PATCH] =?utf8?q?=D0=92=D1=82=D0=BE=D1=80=D0=B0=D1=8F=20=D0=B2?= =?utf8?q?=D0=B5=D1=80=D1=81=D0=B8=D1=8F=20schwabrak?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit Год назад (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 наверняка есть в каждом дистрибутиве. А если и нет, то собираются легко, без зависимостей. Но пока это всё выглядит куда удобнее для работы. -- 2.48.1