On Fri, 17 Oct 2014 17:54:55 +0100, Leandro Lucarella
wrote:
Regan Heath, el 17 de October a las 15:43 me escribiste:
I think you've mistook my tone. I am not "religious" about this. I
just think it's a bad idea for a program to alter behaviour based on
a largely invisible thing (environment variable). It's far better
to have a command line switch staring you in the face.
But it's not the same. I don't mean to be rude, but all you (and Walter)
are saying about environment is evidence of not knowing how useful they
are in POSIX OSs
I am aware of how they are used as I have had to deal with them in the
past. :)
what's the history in those OSs and what people expect from them.
D is not simply for these OSs and should be as platform agnostic as
possible for core functionality.
All these fear about how this can obscurely affect programs
is totally unfunded. That just does not happen. Not at least commonly
enough to ignore all the other advantages of it.
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.
If you keep denying it usefulness and how they are different from
command-line arguments, we'll keep going in circles.
I am not denying they are useful. I am denying they are *better* than a
command line argument *for this specific use case*
Plus as Walter mentioned the environment variable is a bit like a
shotgun, it could potentially affect every program executed from
that context.
We have a product here which uses env vars for trace flags and
(without having separate var for each process) you cannot turn on
trace for a single process in an execution tree, instead each child
inherits the parent environment and starts to trace.
So, your example is a D program, that spawns other D programs, so if you
set an environment variable to affect the behaviour of the starting
program, you affect also the behaviour of the child programs.
Yes. How do you control which of these programs is affected by your
global-affects-all-D-programs-env-var?
This is a good example, and I can argue for environment variables for
the same
reason. If I want to debug this whole mess, using command-line options
there is no way I can affect the whole execution tree to log useful
debug information.
Sure you can. You can do whatever you like with an argument, including
passing a debug argument to sub-processes as required. Or, you could use
custom env vars to do the same thing.
What you *do not* want is a global env var that indiscriminately affects
every program that sees it, this gives you no control.
See, you proved my point, environment variables and
command-line arguments are different and thus, useful for different
situations.
Sure, but the point is that a global env var that silently controls *all*
D programs is a shotgun blast, and we want a needle.
And.. when some of those flags have different meanings in different
processes it gets even worse.
Why would they? Don't create problems where there are any :)
Sadly it exists .. I inherited it (the source is 20+ years old).
Especially if one of those flags prints
debugging to stdout, and the process is run as a child where
input/output are parsed.. it just plain doesn't work. It's a mess.
If you write to stdout (without giving the option to write to a log
file) then what you did is just broken. Again, there is no point in
inventing theoretical situations where you can screw anything up. You
can always fabricate those. Let's stay on the domain of reality :)
Sadly not theoretical.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
