[klhugo]

Quick comment, not an expert, but environ vars keep their state after the program is called. From a functional programming perspective, or just for my own sanity, wouldn’t it be more interesting to keep the states into minimum?

[chriswarbo]

You're right that mutable state should be kept to a minimum, but immutable state is fine. There usually isn't much need to mutate env vars.

Some thoughts/remarks:

- If we don't change a variable/value then it's immutable. Some languages let us enforce this (e.g. 'const'), which is nice, but we shouldn't worry too much if our language doesn't.

- We're violating 'single source of truth' if we have some parts of our code reading the env var, and some reading from a normal language variable. This also applies to arguments through.

- Reading from an env var is an I/O effect, which we should minimise.

- We can solve the last 2 problems by reading each env var once, up-front, then passing the result around as a normal value (i.e. functional core, imperative shell)

- Env vars are easy to shadow, e.g. if our script uses variables FOO and BAR, we can use a different value for BAR within a sub-command, e.g. in bash:

    BAR=abc someCommand

This will inherit 'FOO' but use a different value of 'BAR'. This isn't mutable state, it's a nested context, more like:

    let foo  = 123
        bar  = "hello"
        baz  = otherCommand
        quux = let bar = "abc"
                in someCommand

As TeMPOraL notes, env vars are more like dynamically scoped variables, whilst most language variables are lexically scoped.

[rabidrat]

That's only if you `export` the vars. You can do `FOO=1 BAR=2 cmd` and FOO and BAR will only have those values for the process and children. This is isomorphic to `cmd --foo=1 --bar=2`.

[treebog]

Absolutely, this is one of the reasons that environment variables are a nightmare to work with