Hacker News Reader

Comment by ajarmst | Hacker News Reader

This attitude is how we ended up with Active Directory. One assumes that the author doesn't spend much time in a command-line environment. The option to set defaults for one's normal working environment is obviously of value, and environment variables are hardly exclusive of configuration files (~/.bashrc, makefiles, ...). The theory that complex syntax and statelessness are inherently good and cost-free is naïve to the point of parody.

The author is correct that "this is the way we have always done it" isn't a good argument in and of itself to persist in a practice. However, they might be rewarded by a few minutes pondering a related idea: "if generations of people---many quite capable of modifying the system to use something else---persist in using something, it's possible they have a reason for doing so other than a deficit in competence or imagination."

View on HN

On the facade environment variables may seem like they're orthogonal to global variables but they're not.

Environment variables are scoped to the current process. This could be your shell, but it could also be a web server. This doesn't make them leak proof, but unlike global variables, environment variables have a scope.

Environment variables are also used more widely as an API. Many CLIs have a command that when self-executed can act as a persistence layer in your shell. This functionality would be impossible without environment variables.

You mentioned the other motherload, which is that environment variables are quite often, again, used to communicate in Makefiles. You can see the natural scoping if you start to kick off an ad-hoc shell process inside a Make target.

I don't get this. From the same perspective you can argue global variables have scope too since they are "scoped to the current process". It's not like other processes can access your global variable, that's a very low bar for a scope.

The difference here is that a running shell (including the shell environments that services run with in) are an abstraction layer about managing processes. Within that abstraction layer, each process can have its own unique environment variables that they can change and manipulate independently. That makes them not global.

Within a process the top level abstraction is the process itself, and anything underneath (class, method, function) will be impacted if another sub-abstraction makes a change to a global variable.

Makes sense, thanks.

> It's not like other processes can access your global variable, that's a very low bar for a scope.

They can read them, in /proc/[PID]/environ

> Environment variables are scoped to the current process.

Obviously this is true in a sense. But for practical purposes, it depends on how the environment variables are set. For example, if I set them in my ~/.bash_profile, they're scoped to all bash processes that my current user runs. If I put them in /etc/profile, they're effectively global.

Depending on the variable, sure, but that's a wide latitude in the interpretation of "global". They're not linked or the same memory in any form or fashion. They're merely identical in value.

True. I was thinking in the context of software deployments where environment variables are commonly used as read-only configuration values once the deployment is made.

Interestingly, reading this blog post, this doesn't seem to be common knowledge. The first comparison of global variables inside a process and environment variables left me wondering. It just felt wrong.

A gripe I have with environment variables is when they are used to modify a programs behavior deep inside it's belly and aren't treated like configuration input similar to program arguments.

Otherwise they are a universal way of configuring applications. Universal is good, universal is nice.

@ajarmst is that last related idea you quoted your own? That’s a powerful expression of how I see human culture: question everything, but remember to respect the ideas of the people who came before you. There might be a baby in the bath water you’re discarding.

Obligatory eponymous law: https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...

It's a restatement of the lesson of Chesterton's Fence.

There is a fence somewhere you wish to get rid of. Nobody around knows why it was there in the first place. No one will let you tear it down until somebody figures out why it was put there in the first place.

The important take away, is that before changing something, one should understand the history of a thing, or one runs the risk of being a victim of the same problem the unknown thing was put in place to address.

Life is way more complicated than the umwelt of any one individual, so it is not safe to just change something without doing the footwork to understand what led it ro be in the first place.

Demonstrate that work has been done, and generally, no one will get in your way.

The sentiment certainly isn’t original. The phrasing sounds like me, though. I can get pretty pedantic.

What do you mean about Active Directory?

Reply on news.ycombinator.com