Все компоненты alterator используют особые переменные среды для определения местоположения основных рабочих каталогов:
ALTERATOR_LIBDIR — бакенды и иные архитектурно-зависимые компоненты. Значение по умолчанию – /usr/lib/alterator
ALTERATOR_DATADIR — описания интерфейсов и иные архитектурно-независимые компоненты. Значение по умолчанию – /usr/share/alterator.
Для обоих переменных допустимо перечисление нескольких каталогов
через двоеточие – в этом случае поиск производится последовательно
в порядке указания имён. Например, если ALTERATOR_DATADIR="/a:/b", то файл ui.scm будет искаться сначала по адресу /a/ui.scm, а потом /b/ui.scm.
Для удобства использования у утилит командной строки
alterator существует ключ '-l', который добавляет текущий каталог
в начало списка каталогов в ALTERATOR_LIBDIR
и ALTERATOR_DATADIR.
Таким образом, находясь в модуле, можно отлаживать и запускать его не устанавливая в систему.
Во третьем случае сервер configd не будет отцепляться
от терминала и будет работать с локальными бакендами
и файлами шаблонов. Для старой системы шаблонов (template-*),
дополнительно существует переменная ALTERATOR_HTMLDIR, которая модифицируется при использовании '-l' аналогично остальным переменным.
Замечание: на данный момент поиск локальных
desktop-файлов работает только при использовании
standalone.layout. Во всех остальных случаях придётся установить
desktop-файл в систему. Причина – пока не очень понятно
как сделать алгоритм объединяющий все desktop-файлы
максимально оптимальным при использовании нескольких каталогов.
Ещё: /usr/bin/alterator-standalone водится в пакете
alterator-standalone-usermode, /usr/sbin/alterator-standalone —
в alterator-standalone
Распространённые ошибки при работе с внешними бакендами.
Внешние бакенды альтератора (backend3) общаются с ядром через
stdin/stdout. С одной стороны – это очень хорошо,
с другой – частенько порождает сложно понимаемые ошибки. Список перечисленных ниже известных проблем является одновременно и пожеланием к будущим внешним бакендам (backend4).
1. Паразитный вывод от утилит – некоторые
утилиты могут неожиданно для автора бакенда произвести печать
чего-нибудь на stdout. В результате альтератор воспримет
это как ответ. В результате может быть выдано сообщение
об неподдерживаемой команде или, что ещё хуже, alterator
просто зависнет. Последнее может происходить в случае, когда
утилита выдала на stdout кавычку, двойную кавычку или скобку,
и alterator начинает ожидать завершения строки.
2. Отсутствие ответа
– можно ошибиться и какая-нибудь из утилит (например grep),
будет висеть и в месте с ней будет висеть и весь
alterator.
3. Два ответа вместо одного – alterator
не сбрасывает буфер чтения перед началом чтения очередного ответа
от бакенда, поэтому если бакенд ответил два раза, ядро
и бакенд начинают работать в «противофазе» выдавая
неожиданные ответы в неожиданных местах. Внешне всё выглядит
как будто модуль то работает, а то не работает.
4. Неверный формат вывода списка
– давным давно alterator стал использовать для вывода списков
странную систему, в которой в отличие от остальных
случаев первым идёт строка с именем. Пользователи не читают
документацию, поэтому часто вместо '(«a» param “pam-pam”) выводят
'(name “a” param “pam-pam”) ... в результате бакенд
не работает.
5. Неверный тип данных в ответе
– бакенд принимает всё как строки, а вот отдаёт
уже данные типизированные в формате scheme. Если
вы выдадите не тот тип, то может рухнуть не очень
аккуратно написанный код где-нибудь в ядре (по этому поводу надо сразу же повесить сообщение об ошибке). А если забудете о квотировании строк, то всё может просто-напросто повиснуть, ожидая окончание строки.
6. Несоответствие бакенда правилам workflow
– в HTML интерфейсе автоматические workflow (такие как form
и card-index) требуют определённого подхода к размещению
параметров в «дереве» бакенда. В GUI вся динамика пока
пишется вручную, поэтому там это не так критично.
Вставка отладочных сообщений
Во внешних бакендах остаётся свободным stderr, поэтому можно
выводить отладочные сообщения именно туда. В нативных бакендах
и во всём остальном alterator свободны и stdout
и stderr. Для вывода в коде scheme рекомендуется
использовать функцию format. Например:
Очень полезно отладить бакенд сначала в интерфейсе командной
строки, а потом уже проверять как он работает
в других более сложных интерфейсах – так будет проще найти
виноватого.
Интерпретация некоторых загадочных сообщений
Если по какой-то причине вы получаете, нечто подобное в fbi
Это означает, что ваш backend спросили,
а он вернул просто слово, а не строку. Для того чтобы
понять, что вас спросили,
лучше всего использовать в вашем backend'е следующую конструкцию
Теперь, если заглянуть в файл /tmp/alterator-debug.txt то можно видеть, какой последним был запрос, допустим это было
Стоит произвести следующую диагностику
На самом деле ответ должен выглядеть как-нибудь
так (полностью зависит от вашей реализации модуля у меня
это мой пример)
Особое внимание на «что-то тут» — кавычки, если писать на shell, то обычно кавычки забывают передать, используют конструкцию “string”, а не "\"string\""