5 ms·

Environment variables are fine when used for things that usually don't change once they're set. For example, XDG_CONFIG_HOME or GOPATH. They are, however, absol

Environment variables are fine when used for things that usually don't change once they're set. For example, XDG_CONFIG_HOME or GOPATH. They are, however, absolutely awful when used to configure values that will probably change inside a session. A good example is BEMENU_OPTS from the bemenu program, which is used to change colors, font etc. Should I relogin into my session just to make a program use dark mode colors? https://github.com/Cloudef/bemenu#environment-variables https://github.com/Cloudef/bemenu#environment-variables In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts or overridden on the command line before executing a command, which is extremely annoying.

oaiey 5y ago
Is not that the exact same thing as global variables vs constants
imiric 5y ago
> In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it. It's no different than setting up an alias, and I'd rather use a wrapper script or alias than have to remember how the app is configured, or search my history for the correct invocation. In fact, environment variables are a very flexible way of configuring an app. They're generic, work the same across apps (no worries about the various ways of specifying flags), avoid the need for a custom configuration file, you can have multiple .env files and load them with env(1), etc. I'm a big fan of following the 12factor[1] approach. [1]: https://12factor.net/config https://12factor.net/config
- ayushnix 5y ago
  > Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it. I don't know about others but I'm not a fan of monstrosity like this https://github.com/ayushnix/dotfiles/commit/2eb66eff8a03a5bf527b07231151d5b40ee8fd9d#diff-6bc65594897f3748474b8f50643ddf944d44eb992c27b682a24f737a7c0a53d1L37 https://github.com/ayushnix/dotfiles/commit/2eb66eff8a03a5bf... If I stuff it into a wrapper script, I'm essentially trying to emulate config files, which is what should've been used in the first place. This is why I prefer using config files rather than creating uglier and harder to maintain wrapper scripts. > I'm a big fan of following the 12factor[1] approach. I guess if you don't want state associated with your deployments, environment variables are better but I would still argue that they aren't manageable when their values become large as shown above or if their numbers start approaching double digits because when that happens, you're essentially emulating config files anyways.
  - imiric 5y ago
    > I don't know about others but I'm not a fan of monstrosity like this I think in that case bemenu is abusing env vars to just stuff CLI arguments in a single one, so it defeats the benefit I mentioned above. It could be argued that having individual env vars for every option is cumbersome and pollutes the environment, but this is practically not a problem. > If I stuff it into a wrapper script, I'm essentially trying to emulate config files, which is what should've been used in the first place. Sure, but I see that as a positive. You don't have to worry about the many configuration file formats and their idiosincracies, where they're located and how they're passed to the application. Environment variables work across language stacks and platforms, are simple to implement and use. > This is why I prefer using config files rather than creating uglier and harder to maintain wrapper scripts. It's a matter of preference I guess, and I also don't use them for every app. In some cases they might be limiting, so a configuration file is the only option, but I appreciate whenever a program reads all configuration from the environment. It certainly simplifies a lot of things, e.g. running it in a container.

oaiey 5y ago

Is not that the exact same thing as global variables vs constants

imiric 5y ago

> In such cases, environment variables lose their intended purpose and they need to be stuffed into wrapper scripts Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it. It's no different than setting up an alias, and I'd rather use a wrapper script or alias than have to remember how the app is configured, or search my history for the correct invocation. In fact, environment variables are a very flexible way of configuring an app. They're generic, work the same across apps (no worries about the various ways of specifying flags), avoid the need for a custom configuration file, you can have multiple .env files and load them with env(1), etc. I'm a big fan of following the 12factor[1] approach. [1]: https://12factor.net/config https://12factor.net/config

ayushnix 5y ago
> Why is this so annoying? It's a very common workflow that allows you to customize how an application behaves and simplify how you run it. I don't know about others but I'm not a fan of monstrosity like this https://github.com/ayushnix/dotfiles/commit/2eb66eff8a03a5bf527b07231151d5b40ee8fd9d#diff-6bc65594897f3748474b8f50643ddf944d44eb992c27b682a24f737a7c0a53d1L37 https://github.com/ayushnix/dotfiles/commit/2eb66eff8a03a5bf... If I stuff it into a wrapper script, I'm essentially trying to emulate config files, which is what should've been used in the first place. This is why I prefer using config files rather than creating uglier and harder to maintain wrapper scripts. > I'm a big fan of following the 12factor[1] approach. I guess if you don't want state associated with your deployments, environment variables are better but I would still argue that they aren't manageable when their values become large as shown above or if their numbers start approaching double digits because when that happens, you're essentially emulating config files anyways.
- imiric 5y ago
  > I don't know about others but I'm not a fan of monstrosity like this I think in that case bemenu is abusing env vars to just stuff CLI arguments in a single one, so it defeats the benefit I mentioned above. It could be argued that having individual env vars for every option is cumbersome and pollutes the environment, but this is practically not a problem. > If I stuff it into a wrapper script, I'm essentially trying to emulate config files, which is what should've been used in the first place. Sure, but I see that as a positive. You don't have to worry about the many configuration file formats and their idiosincracies, where they're located and how they're passed to the application. Environment variables work across language stacks and platforms, are simple to implement and use. > This is why I prefer using config files rather than creating uglier and harder to maintain wrapper scripts. It's a matter of preference I guess, and I also don't use them for every app. In some cases they might be limiting, so a configuration file is the only option, but I appreciate whenever a program reads all configuration from the environment. It certainly simplifies a lot of things, e.g. running it in a container.