Hacker News Reader

Comment by philsnow | Hacker News Reader

> It would have been much better to utilize environment variables so the only thing that changed between environments was those variables.

I strongly prefer commandline arguments to environment variables: They're more transparent, easier to reason about ("what's running on this server? `ps`... oh, that process there is running in the staging configuration instead of production"), and it saves useless sudos (/proc/<pid>/environ has mod bits 0400, so if the processes you're investigating are running as separate users (and they probably should be), you can't inspect the actual environment that the process has, so you end up sudo'ing to check the environment out when you should have all the information you need in the process list).

If the environment variables are just interpolated into the run script by the deploy and then all passed to the process as arguments, that works too.

View on HN

Also depending on how those processes are started (as root, from initd, or by hand from shell etc) environment variables might be stripped or incomplete.

Environment variables are kind of like global variables a bit. They are easy to set but feel a little dirty.

And of course if you use libraries or third party package that rely on them, then you don't have a choice.

I strongly agree.

Often times environmental variables are used inappropriately and make tracking down issues harder due to loss of transparency.

Plus environmental variables are context specific (e.g. user 1 and user 2 might have different ones, or server 1 and server 2 might, or this specific script may have re-defined one(!)).

A good o' fashioned script with the constants defined at the top, commented, and passed into executables on the command line (so tools like ps or taskman can "see" them) is really easy to debug/alter/monitor.

Java and or Oracle's obsession with environmental variables causes more problems than it solves.

I also agree, the only way I would use environment variables is for global configuration like HTTP_PROXY for example, otherwise I still prefer arguments, at least there is no surprises.

I agree but I also use DEBUG in my scripts to allow for on the fly debugging to occur.

I consider it a degenerate case and its only there for my own use and abuse. All it really does is redefines certain functions to be more verbose or print out debug level information.

I had one script that let you do DEBUG=somefunc and it would instrument just that one function. But to be honest it was overkill.

I was sad when I learned about this http_proxy environment variable and that things were actually starting to use it.

An http proxy setting is no more suited for an environment variable than anything else. I think it should just be a string in a file in $XDG_CONFIG_DIR/http_proxy.conf or something like that.

Container runtimes like docker make it much easier to inspect the application environment and arguments. A short `docker inspect <id>` will show you everything that is relevant to the app (environment, arguments, and much more).

One thing not to forget is that env variables are inherited by children, which may be relevant if the app forks.

Environment variables make perfect sense for constants that only, you know, vary with the environment. It's very nice to run the same exact code/artifacts on dev, qa, testing and production.