Базовые принципы коммуникации "пользователь -> приложение" Всех приветствую на том конце провода. Сегодня коротенько рассмотрим базовые способы того, как пользователю можно повлиять на поведение программы, если она это допускает и предусматривает. Обозреваемые концепты относятся к исполняемым файлам в целом, поэтому затрагивают и динамические библиотеки. Некоторые из нас в курсе про какие-нибудь механизмы IPC (Inter Process Communications), как например: DBUS. IPC подразумевает коммуникацию между приложениями. Выглядеть она может следующим образом "пользователь -> приложение_1 -> приложение_2". Причем пользователь в этой схеме не является ключевой сущностью - он может как-то повлиять на "приложение_1" и затригерить его обратиться к "приложение_2". Коммуникация "пользователь -> приложение" обычно реализована 3 способами: конфиги, переменные окружения, аргументы командной строки: Общение через файлы конфигурации Приложение может давать пользователю влиять на внутреннюю кухню через конфиги. Тут, чтобы понять, есть ли такая возможность, можно либо почитать описание утилиты, которое она обычно предоставляет, либо посмотреть на список установленных файлов:

# читаем мануал к программе
$ man picom
# смотрим на список установленных файлов
$ dpkg -L picom

Для удобства, в последнем случае можно "грепнуть" вывод, т.к. обычно конфиги заканчиваются ".cnf" и ".conf":

$ dpkg -L picom | grep -e .conf -e .cnf
/usr/share/doc/picom/examples/picom.sample.conf

Также стоит упомянуть тот факт, что конфиги бывают пользовательскими и системными. Пользовательские, как правило, имеют больший приоритет и расположены в скрытой директории внутри хомяка "~/.config". Системные, в свою очередь, где-то внутри "/etc/":

$ dpkg -L openssl | grep -e .conf -e .cnf
/etc/ssl/openssl.cnf

Общение через переменные окружения Приложение может поддерживать коннект с пользователем и обрабатывать запросы в том числе и через переменные. Если мы посмотрим на мануал к проекту mesa, сколько же там всего можно проконтролировать, оставляю ссылочку. Аналогичная история и с такими проектами, как gtk, kwin и т.д. Если приложение допускает кастомизацию одних и тех же параметров и через файлы и через проставление переменных окружения, то переменные, как правило, имеют больший приоритет. Общение через переменные происходит обычно по 3 сценариям: 1) мы определяем переменную для конкретного пользователя, например через файл "~/.bashrc". В таком случае, каждый раз, как пользователь открывает сессию, переменная становится видимой для приложений внутри:

$ cat ~/.bashrc
export SOME_VARIABLE="some value"

2) мы определяем общесистемную переменную "/etc/environment", которая доступна приложениям любой сессии и всем пользователям:

$ cat /etc/environment
SOME_VARIABLE="some value"

3) мы передаем переменную программе на старте. В результате, только целевая программа и ее потомки будут видеть переменную и смогут с ней работать:

$ SOME_VARIABLE="some value" picom

Общение через аргументы командной строки Еще одна полезная опция - передавать программе определенный пулл параметром через CLI (Command line interface) в момент запуска. Такой формат очень распространен в "no-GUI" утилитах, работа с которыми происходит исключительно в командной строке: nmcli, pkcs11-tool, ssh и т.д.:

$ pkcs11-tool --module /usr/lib/librtpkcs11ecp.so -T

Список параметров программа, как правило, выдает через флаг "--help":

$ nmcli --help

nmcli [ПАРАМЕТРЫ] ОБЪЕКТ { КОМАНДА | help }
ПАРАМЕТРЫ
-a, --ask  запрос отсутствующих параметров

Linux++ | IT-Образование