8 ms·

Strongly disagree. Environment variables are, IMHO, best tool for some simple configuration in unix. They match perfectly with behavior of the ecosystem and ot

Strongly disagree. Environment variables are, IMHO, best tool for some simple configuration in unix. They match perfectly with behavior of the ecosystem and other tools in it (like unix shell). Yes, if your OS is some unversal JS machine, then JSON would be better, if it is Lisp machine, then you would use S-expressions, but on Unix machine, environment/args are way to go. There are two realistic alternatives - config files and arguments. They have each their own niche, where environment is somehwere between them. Arguments are better for one-shot setting, not for some setting used always. You can use 'alias' to define shortcuts that always add some argument, but that is definitely more cumbersome. Config files are good for always/default setting, but are too rigid. Changing config files is equivalent of changing global variable in code, it has system/user-wide effect. While i can just change environment in this one shell and it will affect just commands executed from that shell. Also, config files are much harded to be manipulated from scripts, and use different syntax for each tool. Perhaps the ideal tool would allow every option to be set/changed from config file, environment and argument.

CGamesPlay 6y ago
> Perhaps the ideal tool would allow every option to be set/changed from config file, environment and argument. This is exactly what the most widely used golang configuration library does: https://github.com/spf13/viper https://github.com/spf13/viper
- jayd16 6y ago
  Its also what most of the entrprisey frameworks do. Spring will do this and I'm pretty sure ASP.NET has some form of it.
- mixmastamyk 6y ago
  I made something similar for Python, with an animal theme too, ha: https://pypi.org/project/tconf/ https://pypi.org/project/tconf/
yrro 6y ago
Why I don't like environment variables: 1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage... 2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems. I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive' and 'noexport', allowing them to opt out of the default behaviour. It would have been so say to say "variables starting with _ are not inherited and should be censored when output", but we're about 40 years too late for that to catch on...
- bopbeepboop 6y ago
  How do command line arguments or config files solve either problem?
  - yrro 6y ago
    Command line arguments aren't inherited by child processes. Unfortunately they are visible to other users on the system, so they're no good for credentials. Config files (or an abstraction of them such as reading config data from a socket), after parsing, result in some credentials sitting in the memory of the process that needs them. They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure won't risk exposing them. And for the same reason, a child process that does the same won't inherit them in order to expose them. Note that talking about preventing accidental exposure of credentials. Config files alone can't protect credentials from a malicious process that deliberately goes looking for them to leak them; for that additional measures have to be taken... but environment variables aren't part of the solution!
    - bopbeepboop 6y ago
      > Unfortunately they are visible to other users on the system, so they're no good for credentials. If you’re concerned about your own software logging credentials, command line arguments are negative in two regards: They’re highly visible when the process is running; they’re often automatically logged. > They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure won't risk exposing them. Okay — but the usual way that happens is “dump my config object in a log”, which parsed configs don’t help with. You also now have a config file: how is it stored? ...is it in the repo? ...what are the permissions? ...how do we deploy it? Environment variables don’t persist in repos and are designed to be integrated with hosting tools, like secrets managers. I’m not seeing how a config file beats Kubernetes injecting from the secret store, which is why we use environment variables: so our tools (secret stores) can configure the environment our software uses.

CGamesPlay 6y ago

> Perhaps the ideal tool would allow every option to be set/changed from config file, environment and argument. This is exactly what the most widely used golang configuration library does: https://github.com/spf13/viper https://github.com/spf13/viper

jayd16 6y ago
Its also what most of the entrprisey frameworks do. Spring will do this and I'm pretty sure ASP.NET has some form of it.
mixmastamyk 6y ago
I made something similar for Python, with an animal theme too, ha: https://pypi.org/project/tconf/ https://pypi.org/project/tconf/

yrro 6y ago

Why I don't like environment variables: 1. I worry about programs dumping all their environment variables to log files - credentials are now on disk, ingested into log storage... 2. Environment variables are inherited by child processes by default. This is undoubtable useful. But it can also cause problems. I wish the ghosts of unix past had forseen the need for a way to mark particular variables as, say, 'sensitive' and 'noexport', allowing them to opt out of the default behaviour. It would have been so say to say "variables starting with _ are not inherited and should be censored when output", but we're about 40 years too late for that to catch on...

bopbeepboop 6y ago
How do command line arguments or config files solve either problem?
- yrro 6y ago
  Command line arguments aren't inherited by child processes. Unfortunately they are visible to other users on the system, so they're no good for credentials. Config files (or an abstraction of them such as reading config data from a socket), after parsing, result in some credentials sitting in the memory of the process that needs them. They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure won't risk exposing them. And for the same reason, a child process that does the same won't inherit them in order to expose them. Note that talking about preventing accidental exposure of credentials. Config files alone can't protect credentials from a malicious process that deliberately goes looking for them to leak them; for that additional measures have to be taken... but environment variables aren't part of the solution!
  - bopbeepboop 6y ago
    > Unfortunately they are visible to other users on the system, so they're no good for credentials. If you’re concerned about your own software logging credentials, command line arguments are negative in two regards: They’re highly visible when the process is running; they’re often automatically logged. > They aren't in the environment block, so a quick and dirty "dump all my environment variables to stdout" procedure won't risk exposing them. Okay — but the usual way that happens is “dump my config object in a log”, which parsed configs don’t help with. You also now have a config file: how is it stored? ...is it in the repo? ...what are the permissions? ...how do we deploy it? Environment variables don’t persist in repos and are designed to be integrated with hosting tools, like secrets managers. I’m not seeing how a config file beats Kubernetes injecting from the secret store, which is why we use environment variables: so our tools (secret stores) can configure the environment our software uses.