Централизованное управление переменными окружения

Тогда это будут не переменные окружения, а open/close/read/write со всеми вытекающими прелестями (никто не будет знать как правильно с этим работать, кроме «как хочешь», «пока не сломается» и «не мои проблемы»).

Переменные окружения в юниксах неизменяемы. Вряд ли линукс позволяет их изменить. Переменные в шелле только делают вид, что их можно изменить.

А вот Plan 9 позволяет изменить переменные окружения для текущего процесса (про дочерние не знаю). Самому интересно почему.

100% звучит, как проблема XY.

Мне, например, выставлять конкретную переменную окружения требуется приблизительно раз в квартал, не чаще. Сложно представитЬ, для чего это может понадобиться на постоянной основе.

Сложно представитЬ, для чего это может понадобиться на постоянной основе.

Я описал в посте, зачем это нужно: для одних программ я хочу переменную E=x, для других E=y, для основной массы она вообще не нужна и не должна быть выставлена.

kaldeon

Тогда это будут не переменные окружения, а open/close/read/write со всеми вытекающими прелестями (никто не будет знать как правильно с этим работать, кроме «как хочешь», «пока не сломается» и «не мои проблемы»).

Они уже не переменные окружения, на самом деле. Половина лялехософта через них конфигурацию тащит, в дополнении к собственно конфигам. Отсюда и хотелка.

Централизованное управление переменными окружения

Такого вообще нет. Есть какие-то приближения вроде pam_env. environment.d работает только для самого systemd и сервисов.

Я описал в посте, зачем это нужно: для одних программ я хочу переменную E=x, для других E=y, для основной массы она вообще не нужна и не должна быть выставлена.

Это решается скриптом-запускалкой для соответвующей программы. По скрипту на программу — они коротенькие же. То, что это будет какой-то дополнительный файл, никак не делает это всё проще — всё равно каждую прогу и переменную прописывать — просто вместо обычного скрипта будет этот странный конфиг — телодвижений, когда хочешь что-то изменить, столько же. Зачем усложнять простое?

Из более костыльных вариантов есть .desktop файлы и подобное.

Это решается скриптом-запускалкой для соответвующей программы. По скрипту на программу — они коротенькие же. То, что это будет какой-то дополнительный файл, никак не делает это всё проще — всё равно каждую прогу и переменную прописывать — просто вместо обычного скрипта будет этот странный конфиг — телодвижений, когда хочешь что-то изменить, столько же. Зачем усложнять простое?

У меня таких скриптов уже десяток. Это не простое.

У меня таких скриптов уже десяток. Это не простое.

Это разве много?

Ну а если будет вместо скрипта файл со своим особым синтаксисом, как это решит твою проблему? Всё равно нужно писать название и значение каждой переменной и команду запуска каждой программы. Просто в другой файл с другим синтаксисом. Телодвижений становится не меньше, а столько же, когда хочешь что-то добавить или изменить, но добавляется ещё один слой абстракции, который ровным счётом ничего не даёт.

Ну ок, по одной строчке на программу экономит — которая #!/bin/sh. Неужели из-за неё весь сырбор?

У меня таких скриптов уже десяток. Это не простое.

Вместо скриптов можно делать это функциями shell (в bash/zsh/fish такая функциональность есть, да и в любом шелле, почти уверен, есть). И все эти функции можно будет положить в один файлик, если это напрягает.

Но цель этих извращений до сих пор непонятна.

Можно пример хотя бы пары программ и пары переменных для них.

Вместо скриптов можно делать это функциями shell (в bash/zsh/fish такая функциональность есть, да и в любом шелле, почти уверен, есть). И все эти функции можно будет положить в один файлик, если это напрягает.

Остаётся придумать, что делать, есть прога запускается не из шелла, а, например, из меню.

Но цель этих извращений до сих пор непонятна.

Цель: управлять этим бардаком из одного файла, не размазывая его по файловой системе.

Можно пример хотя бы пары программ и пары переменных для них.

Да легко. Некоторый софт на GTK3 дико сломан под Wayland и его лучше запускать через XWayland. Соответственно, GDK_BACKEND=x11 нужно выставить только им, но не всей системе.

Чем не подходит установка переменной в .desktop?

Если прям хочется один файлик, то можно приблизиться к этой цели: написать команду, которая будет искать переменные окружения во всех .desktop файлах. И ты будешь знать где что находится и открывать эти места из одного места.

для основной массы она вообще не нужна и не должна быть выставлена

Наркоман? Это не мешает приложению, не понятно почему это вдруг помешало тебе.

Principle of least privilege

Это когда тебе нужно передать в переменной sensitive data. 99% переменных это какой-нибудь LSCOLORS или XDG_CONFIG_HOME (последний вообще дефлотится в $HOME/.config, если не указан явно).

Это когда тебе нужно передать в переменной sensitive data.

Дело не в чувствительных данных – их передавать через переменные окружения вообще очень тупая идея. Дело в том, что с современной культурой программирования никогда не угадаешь имена переменных, которые какая-нибудь софтина использует.

Чем не подходит установка переменной в .desktop?

Тем, что .desktop файлы лежат в / и перезатираются при обновлении пакетов.

Если прям хочется один файлик, то можно приблизиться к этой цели: написать команду, которая будет искать переменные окружения во всех .desktop файлах. И ты будешь знать где что находится и открывать эти места из одного места.

Можно наговнокодить и накостылить, я знаю. Я интересуюсь здесь существованием готового решения моей проблемы, потому как очень сомневаюсь, что я – прямо первый пользователь пердоликса, кому такое в голову вообще пришло.

Это на десктопе так. А сегодня через енвы конфиги всякие кидают. Хотя там может и не быть паролей, нежелательная информация всегда может проскочить.

Тем, что .desktop файлы лежат в / и перезатираются при обновлении пакетов.

Ну и скопируйте нужные в ~/.local/share/applications, они в приоритете относительно /usr/share/applications

Тем, что .desktop файлы лежат в / и перезатираются при обновлении пакетов.

Ну и скопируйте нужные в~/.local/share/applications, они в приоритете относительно/usr/share/applications

Тогда придётся следить за синхронизацией того, что в /usr/share/application и локальных, и чтобы они отличались только переменными окружения. План – огонь!

Можно наговнокодить и накостылить

Если задача не сложная и укладывается в условные 5 минут, норм.

Я интересуюсь здесь существованием готового решения моей проблемы

systemd? Там можно ставить Environment и наследоваться от системных юнитов. Но тогда и все программы надо в нём же запускать. Это возможно, но так не делают (пока что), хотя лично я не вижу препятствий.

Можно наговнокодить и накостылить

Если задача не сложная и укладывается в условные 5 минут, норм.

Да не, не норм. Через три дня я забуду как это всё работает, через три месяца я буду офигивать от костылей и попыток разобраться в них.

Я интересуюсь здесь существованием готового решения моей проблемы

systemd? Там можно ставить Environment и наследоваться от системных юнитов. Но тогда и все программы надо в нём же запускать. Это возможно, но так не делают (пока что), хотя лично я не вижу препятствий.

Как мне унаследовать emacs от системного юнита? Systemd тут явно не подходит.

Цель: управлять этим бардаком из одного файла, не размазывая его по файловой системе.

Не очень понятно, зачем. Жёстко ограничено количество inode, так что десяток (или даже несколько десятков) файлов вместо одного — проблема? Обычно наоборот стараются разделять конфиги…

Если дело не в inode и ФС, а в каких-то личных психологических особенностях при редактировании файлов, то в принципе можно просто набросать скрипт, который будет отслеживать этот «единый файл» (можно даже просто запускать его про incron) и генерить на его основе пачку скриптов. Как по мне, это тоже лишнее переусложнение — нет ничего удобнее обычных скриптов — но если прям очень хочется, чтобы в одном файле было, то почему бы и нет. Там делов-то на <10 строчек скрипта.

Как мне унаследовать emacs от системного юнита?

Под системным я имел ввиду проживающий в /usr/lib/systemd/user. А так-то он пользовательский. Создаёшь свой юнит в $home/.config/systemd/user, делаешь туда .include системного юнита, переопределяешь Environment.

Чего там отслеживать, смену иконки или переводы?

Например меня не устраивает название Web Browser, я скопировал xfce4-web-browser.desktop и изменил Name и Icon на firefox

Какой-нибудь xfce4-mail-reader.desktop за ненадобностью скрыл NoDisplay=true

Отредактируйте в нужном desktop-файле Exec=ENVIRONMENT1=1 ENVIRONMENT2=2 proga params

Через три дня я забуду как это всё работает

Если там делов на 5 минут, то не забудешь. Это, по сути, просто сложный греп.

Программистам регулярно приходится писать поисковые запросы, чтобы надвигаться по проекту, здесь то же самое.

Не больше 5 минут заняло:

find $home |grep '/Info\.plist$' |for (f in `{cat}) {
	echo $f
	sed -n '/<key>/ {
		s/<\/?key>//g
		p
	}' $f |mc
}

Печатает название файла и под ним все ключи в несколько столбцов. У меня нет линукса под рукой, но по идее адаптировать под переменные окружения не сложно.

Пофиг что оно ограничено и не будет срабатывать в 99.99% сценариев. Это просто чтобы жилось легче, не более.

Написать программу/скрипт myenv prog ..., в котором фильтровать запускаемые программы для настойки своих переменных окружения, можно из отдельного конфига. Программы запускать посредством этого скрипта.

Или хочется перехватить сисколы exec*? login со своим LD_PRELOAD?

Перезатираются, потому что ты не хозяин своей системы. Почему решил, что с какой-то переменной будет иначе.

Какая к чёрту синхронизация, если сам говоришь, что там должно быть особое твоё. Сначала в себе разберись.

Ты же nix[pkgs|os] практикуешь. Какие проблемы перегрузить пакет своими переменными окружения в оверлее?

Тогда остаётся один путь: модифицировать ядро. Скорее всего, это будет даже не запредельно сложно. Но гораздо затратнее по усилиям и времени, чем все остальные предложенные решения, включая это.

Ты же nix[pkgs|os] практикуешь. Какие проблемы перегрузить пакет своими переменными окружения в оверлее?

Да, я вот про это уже и думаю. Но вдруг есть что-то красивее. Так-то package-overrides с врапперами никто не отменял.

Ты ж программист. Напиши шпареную библиотеку, которая будет читать свой глобальный конфиг с переменными окружения для программ и выставлять эти переменные в своём процессе. И пропиши эту библиотеку в /etc/ld.so.preload.

Здесь скриншот. На скриншоте. Слева, меню - это десктоп-файл и никто его не перезапишет.

И пропиши эту библиотеку в /etc/ld.so.preload

Не будет работать с программами, собранными статически, если я правильно понимаю.

следить за синхронизацией

И что же там постоянно меняется?

Ты ж программист. Напиши шпареную библиотеку, которая будет читать свой глобальный конфиг с переменными окружения для программ и выставлять эти переменные в своём процессе. И пропиши эту библиотеку в /etc/ld.so.preload.

Кстати, неиронично пока самая лучшая идея в этом треде. Спасибо за мысль, я об этом подумаю.

Безо всякого ИИ:

oplist=/home/user/options
proga=$(zenity --width=350 --height=700 --list --column="select:" `awk -F^ ' ! /^#/ { print $1 } ' $oplist` )
options=${awk -F^ " ! /^#/ && /$proga/ { print $2 } " $oplist } 
$proga $options

Тем, что .desktop файлы лежат в / и перезатираются при обновлении пакетов.

Ну так ты правь те, которые лежат в ~/.share/application. Они-то никуда не денутся.

А так, в голову приходит тупая идея впихивания в лаунчер (типа rofi/fuzzel) функционала, чтобы он предварительно искал запускаемый бинарь например в кастомном json и поттягивал переменные оттуда.

Но сам бы я наверное просто позаворачивал в алиасы ~/.bashrc

Ну и скопируйте нужные в ~/.local/share/applications

Я тоже так думал, пока чертова громоптица забила на файлы из хомяка и не начала открывать браузер из /usr/share/applications.

PS: Руки бы им вырвать за такое, да.

А она точно открывает десктоп-файл? Может напрямую приложение, например /usr/lib/firefox/firefox или sh-обёртку /usr/bin/firefox

Точно. При замене desktop-файла в /usr/share/applications, всё начинает работать как надо. И проблема только с громоптицей, другие приложения открывают браузер как надо.

Думаю, скрипты-обёртки - меньший и менее проблемный костыль, чем то что ты хочешь.

В той же убунте используются скрипты-обёртки, а там программисты сидели и думали на тему. Значит, ничего лучшего нет.

Заведи себе ~/bin, положи его в PATH с наивысшим приоритетом, сделай там скрипт типа envstart типа такого:

#!/bin/sh

if [ "$0" == "Program1" ]; then
export ENV1=bar
export ENV2=baz
$0 $*
fi

if [ "$0" == "Program2" ]; then
export ENV1=bar2
export ENV2=baz3
$0 $*
fi

exit 0

Ну или вообще на питоне напиши, можно будет в массив положить, а переменные отдельно вынести. Или в шелле прочитать внешний файл и распарсить. Короче, что тебе больше нравится. Дальше в том же ~/bin делаешь симлинки вида ~/bin/program1 -> ~/bin/envstart.

Как тебе идея?

Насчет Thunderbird не знаю, но по идее в DE (насчет WM не скажу) должна быть декларация, как в крысе xfce4-web-browser.desktop, десктоп файл, который открывает браузер по-умолчанию, но при этом в /usr/share/applications есть и firefox.desktop. Поэтому не знаю, чем громоптица руководствутся. Если она не учитывает пользовательское окружение, то что тут скажешь, наверное mime-типом text/uri-list или чем-то наподобие.

grep 'firefox' /usr/share/applications/mimeinfo.cache

Наверное можно создать в хомяке и в там настроить.

В той же убунте используются скрипты-обёртки, а там программисты сидели и думали на тему. Значит, ничего лучшего нет.

Да нет, вообще не значит.

Как тебе идея?

Так себе идея. Не работает, если одна прога запускает другую, используя полный путь. Это так, навскидку. Наверняка есть и другие проблемы.