[Request/Question] Allow control over if/how the $env var is exposed

[prateek]

I'm considering using expr at DAYJOB and would like to not expose the $env var using that name. We're planning on using expr as a DSL and the domain has vars which conflict with $env and/or look similar enough that I want to stray from any confusion.

I skimmed thru the code and it doesn't look like I can hide it from the expr programs via configuration today. Please call out if I just missed that.

Questions I have for you:

• Does this var need to be exposed to end users? I can understand the convenience of it, but do you see it as a must have or a nice to have?
• Would you be amenable to allowing it to be exposed under a different name? If not, would you be amenable to allowing it to not be exposed (something like the DisableBuiltin() directive)?

I'm happy to do the work to support my request but I wanted to ask before I went and put up a PR that doesn't align with your direction for expr.

[mdmcconnell]

It looks like a handful of users have found $env to be a useful convenience, so perhaps it is preferable to add a directive to disable it, versus remove or rename.

[antonmedv]

Does this var need to be exposed to end users? I can understand the convenience of it, but do you see it as a must have or a nice to have?

In some cases, vars in env can contain dashes or spaces some-field or some var.

So using $env is convinient: $env["smoe-field"] == 42

Would you be amenable to allowing it to be exposed under a different name? If not, would you be amenable to allowing it to not be exposed (something like the DisableBuiltin() directive)?

Sure. I think we can make $env configurable. Let's make DisableBuiltin("$env") work.