On Mon, 20 Oct 2014 18:19:33 +0100, Sean Kelly <s...@invisibleduck.org> wrote:

On Monday, 20 October 2014 at 10:39:28 UTC, Regan Heath wrote:

Sure, but past/current env vars being used are used *privately* to a single program. What you're suggesting here are env vars which will affect *all* D programs that see them. If D takes over the world as we all hope it will then this will be a significantly different situation to what you are used to.

I'm not advocating the approach, but you could create a "run_d"
app that simply set the relevant environment args and then
executed the specified app as a child process.  The args would be
picked up by the app without touching the system environment.
This would work on Windows as well as on *nix.

Sure, but in this case passing an argument is both simpler and clearer (intent).

This is basically trying to shoehorn something in where it was never intended to be used, envvars by design are supposed to affect everything running in the environment and they're the wrong tool for the job if you want to target specific processes, which IMO is a requirement we have.

A specific example. Imagine we have the equivalent of the windows CRT debug malloc feature bits, i.e. never free or track all allocations etc. These features are very useful, but they are costly. Turning them on for an entire process tree may be unworkable - it may be too slow or consume too much memory. A more targeted approach is required.

There are plenty of options, but a global envvar is not one of them.


Using Opera's revolutionary email client: http://www.opera.com/mail/

Reply via email to