D2 port of Sociomantic CDGC available for early experiments

[Leandro Lucarella via Digitalmars-d-announce]

Regan Heath, el 17 de October a las 15:43 me escribiste:
> >>You've got it backwards.  I'm looking for a *better* solution than
> >>environment variables, which are a truly horrid way to control
> >>runtime behaviour IMHO.
> >
> >OK, then this is now a holly war. So I'll drop it here.
> 
> 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, what's the history in those OSs and what people expect
from them. 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.

If you keep denying it usefulness and how they are different from
command-line arguments, we'll keep going in circles.

> 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. 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. See, you proved my point, environment variables and
command-line arguments are different and thus, useful for different
situations.

> 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 :)

> 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 :)

In all the years I've been working in Linux I never, EVER came across
problems with environment variables being accidentally set. I find it
very hard to believe this is a real problem. On the other hand, they
saved my ass several times (LD_PRELOAD I LOVE YOU).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
Le pedí que me enseñe a usar el mouse
Pero solo quiere hablarme del Bauhaus
Le pregunté si era chorra o rockera
Me dijo "Gertrude Stein era re-tortillera"
Me hizo mucho mal la cumbiera intelectual