Re: coreutils feature requests?

[Kaz Kylheku (Coreutils)]

On 19.07.2017 10:03, Lance E Sloan wrote:
> With regard to your objection to a special environment variable: I 
> agree.
> I didn't feel strongly about it at first, but I was leaning towards not
> implementing env. var. support for this.  It just didn't feel right.  I
> have written programs that use env. var. to specify or override default
> options.  However, your point about adding this to an existing, 
> established
> program where it could possibly cause variable conflicts is enough to 
> set
> my option a little more strongly against an env. var. for this purpose.

My own objection to such influencing env-vars is rooted in
"global variables are bad"; i.e. the inherited wisdom from decades
of computer science and software engineering practice.

Say you want to combine code from two or more scripts, all of which
want to configure the same tools in different ways via globals. Now
you have a mess of saving and restoring the global so that it
has the value that each bit of code expects when that code is running.

With magic globals we can't look at a line of code and know exactly
what it will do, without reasoning about what are the current values
of the globals. That reasoning may be intractable: i.e. situations in
which it simply cannot be known. Then the code has to ensure that the
variables have certain values by assigning them. Except, it can't
just assign because that will influence some other code; it has to
save the prior values, then assign, then restore when done.

Of course environment variables can be scoped:

   OPT=value command

but that's local syntax now, which defeats the purpose of the
"action at a distance" effect of the variable; it might as well be
transliterated to:

   command --opt=value

and there we are.