История изменений

Нет. getenv позволяет использовать разные ветки в зависимости от настроек окружения,

Это и есть костыли и отладка.

тогда удобно при развертке в контейнере устанавливать env типа INSTANCE_SERVER=bic15.irrpo.net чтобы программа брала его оттуда

Это надо в конфиг-файле указывать а не в env. Ну или аргументом командной строки иногда.

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

Ну да, используешь дефективную «систему деплоя», а виноваты оказываются конфиги.

Есть, но редко. Например в программе есть код, который в случае установленного env SERVER использует его. Но бывают случаи, когда на данной машине в данных обстоятельствах его использовать нельзя (т.е. необходимо заоверрайдить то, что написано в env), к примеру, если программа запущена с опцией –secure, которая (для примера) запрещает выход за пределы контура. Тогда, вместо того, чтобы лепить в коде, который использует SERVER какие-то проверки удобнее на этапе инициализации сделать setenv(SERVER, ). Да, это меняет ожидаемое поведение, но иногда необходимо.

Я писал что нормального применения не знаю, а ты в ответ в пример приводишь ненормальное. Во-первых, уже описанное выше костыльное использование env вместо конфига/аргументов. Во-вторых, неосиливание этот env заменить в вызвающем скрипте и вместо этого накидывание ещё костылей в бинарник. В-третьих, вместо того чтобы на старте программы спарсить все эти дефективные env, раскидать по переменным и пользоваться уже ими - подмена env чтобы кто-то где-то внутри его потом парсил. Ужас.

-----

env - это средство задания общесистемных настроек для заранее неизвестного круга процессов, которые кто-то когда-то будет запускать. Абузить их для передачи проге её индивидуальных настроек - костыль и плохо. Абузить их для передачи информации между разными функциями внутри одного бинарника - это вообще дичь.

Нет. getenv позволяет использовать разные ветки в зависимости от настроек окружения,

Это и есть костыли и отладка.

тогда удобно при развертке в контейнере устанавливать env типа INSTANCE_SERVER=bic15.irrpo.net чтобы программа брала его оттуда

Это надо в конфиг-файле указывать а не в env. Ну или аргументом командной строки иногда.

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

Ну да, используешь дефективную «систему деплоя», а виноваты оказываются конфиги.

Есть, но редко. Например в программе есть код, который в случае установленного env SERVER использует его. Но бывают случаи, когда на данной машине в данных обстоятельствах его использовать нельзя (т.е. необходимо заоверрайдить то, что написано в env), к примеру, если программа запущена с опцией –secure, которая (для примера) запрещает выход за пределы контура. Тогда, вместо того, чтобы лепить в коде, который использует SERVER какие-то проверки удобнее на этапе инициализации сделать setenv(SERVER, ). Да, это меняет ожидаемое поведение, но иногда необходимо.

Я писал что нормального применения не знаю, а ты в ответ в пример приводишь ненормальное. Во-первых, уже описанное выше костыльное использование env вместо конфига/аргументов. Во-вторых, неосиливание этот env заменить в вызвающем скрипте и вместо этого накидывание ещё костылей в бинарник. В-третьих, вместо того чтобы на старте программы спарсить все эти дефективные env, раскидать по переменным и пользоваться уже ими - подмена env чтобы кто-то где-то внутри его потом парсил. Ужас.