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.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
