D2 port of Sociomantic CDGC available for early experiments
Regan Heath via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Mon Oct 20 03:39:28 PDT 2014
On Fri, 17 Oct 2014 17:54:55 +0100, Leandro Lucarella <luca at llucax.com.ar>
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/
More information about the Digitalmars-d-announce
mailing list