81–90 of 296 posts
Relatedly https://boakye.yiadom.org/bikeshed/env/ In short, I'm in full agreement with the author on not implicitly using magic variables/values in our programs. Environment variables are fine so long as they're not read from within the depths of a function.
I hope I don't get downvoted, but I think the OP has a point. Command line arguments will do, and perhaps even be better. Why are there so many harsh comments about this post?
In addition to what's said in the post, environment variables have one more significant, practical shortcoming: if an application 'foo' takes a FOO_LOGDIR (which defaults to /var/log/foo if unset) and you accidentally slip it a FOO_LODGIR=/run/log/foo - it will silently accept and ignore it, while you will be scratching your head why is the logging not behaving as expected, until you discover the typo.
Naturally, 'foo' could ensure no FOO_* with unknown names are set. But I've yet to see an application like this in practice, while nearly every single flag parsing library out there immediately errors out on unknown flags.
I disagree with this post so strongly - having spent most of my career installing, configuring, and managing other people’s software. > The answer is that you, the end user, can not now. Every program is free to do its own thing and most do. If you have ever spent ages wondering why the exact same commands work when run from one terminal but not the other, this is probably why. If the same program is behaving differe…
The same can be said for command line arguments. I usually prefer those instead of environment variables, because they must be explicitly specified instead of being implicitly passed by the parent process. I think of env vars as being more useful when repetitively calling commands interactively, to save some typing, or when you really do want processes to inherit config from parents (like PATH and its variants).
But overall I still agree with your sentiment.
I hope I don't get downvoted, but I think the OP has a point. Command line arguments will do, and perhaps even be better. Why are there so many harsh comments about this post?
I am having hard time figuring these out. So I rarely use environment variables.
I disagree with this post so strongly - having spent most of my career installing, configuring, and managing other people’s software. > The answer is that you, the end user, can not now. Every program is free to do its own thing and most do. If you have ever spent ages wondering why the exact same commands work when run from one terminal but not the other, this is probably why. If the same program is behaving differe…
I have a pet peeve about this attitude. These methods are being used for decades and well understood with all their advantages and disadvantages. One day, someone comes and tells that it's bad and considered harmful , and happily tells the only right way to do it . A flame war ensues then. I'm all for moving things forward and evolution, but can't we take a milder stance and move forward in a more peaceful way? Attac…
I disagree. Very often, the 'easiest' option wins, not the one that necessarily is the 'best', especially in the long term. Environment variables for configurations are fast and easy, and work well on the happy path - but break down quite fast when dealing with more complex cases (eg. more complex types than strings). They have a treacherous way of seeming the simplest and most pragmatic solution at first, but becoming a an untyped, underdocumented hairball after some time in more complex software.
Furthermore, as long as environments have existed in UNIX and UNIX-like derivatives, their usage to configure the bulk of the behaviour of most services/programs are relatively new. The more old-school the service you deploy somewhere, the more likely it has a file-driven config. Indeed, sometimes it seems like 90% of the Docker code out there is converting environment variables into configuration files.
Earlier quoted context omitted.
I have no skin in this game, so to speak, so just curios. What kind of ways did you get burned by other things than env vars in a way in which env vars would not?
Mostly configuration stored in the database (who configures the database) or 3rd party configuration services without an SLA and config files that are either present or not. Env vars are really simple since they are completely decoupled from the app and you can have default values for all of them. You just need a single class that loads all config on startup and you can go from there (or fail if you don't have the ma…
I hope I don't get downvoted, but I think the OP has a point. Command line arguments will do, and perhaps even be better. Why are there so many harsh comments about this post?
Env vars are a built-in for key-value command line args. Why introduce some custom convoluted way into your app for kv args instead of this standardised approach. I can understand why some heavily used cli app would support a custom parameter pattern, eg. for ergonomics, but for majority of apps running as deployed services and not cli apps invoked 100 times a day, I don't see a reason to not use env args. I can run…