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