ENVVars Removal and functional replacements (was Re: coreutils feature requests?)

[L A Walsh]

Kaz Kylheku (Coreutils) wrote:
> On 19.07.2017 10:03, Lance E Sloan wrote:
> > With regard to your objection to a special environment variable: ..
> 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.
----
   Sorry to interject here, but I have to point out the evils
"that everyone knows" about getting rid of ENV vars.
I don't believe you should put comments about ENV vars in the same
sentence as "inherited Wisdom" or global variables (that are
hidden in binaries).  I would say that most of the universe
would be very inconvenienced were ENV vars to be removed, and that
doing so, tool-by-tool is a way to generate workarounds that
are far worse. 

   Look at use of env vars for HOME, LOCALE support, COLOR preferences,
flags (CFLAGS, CFLAGS) various tools default options... the list is
endless.  99% of the problems of ENV vars are caused by bad design, not
the Env vars.  Several examples of that are applying ENV vars that are
really meant for *interactive use*, to run-time use all the time.

   Any script that people think has a problem w/ENV vars can use
"env -i SCRIPT".  That clears all Env vars.  If you want to
remove all ENV vars starting with LESS, you can just as easily
do that:
env -u ${!LESS*} SCRIPT

The problem comes with those who don't know how to use env
vars and those too lazy to be troubled to clean the env to
what they want.

As soon as you show replacements for things like PATH, HOME, etc,
that work as defaults for all utils, I might agree, but the gnu
utils are becoming more broken over time as they disallow setting
up defaults for a given-machine's interactive use that don't
just work in some shell.

Alias and shell funcs aren't the answer, as they are not referenced
when you do something as as simple as "sudo xxyz", or similar. 
You *can* configure sudo to _allow_ ENV vars to be propagated,
but you can't do that with aliases.  Nether can you reliably
have functions work with sudo -- early version, yes, and late versions,
yes, but that's not exactly reliable -- and they don't work
at all unless the command goes through a function-compatible
shell.


FWIW, you remove env vars, and you end up with people doing things
like:

mv /usr/bin/CMD /usr/bin/CMD.bin
echo -e "#!/bin/sh\n[set ENVVARS & CMD flags]\n
       exec -a CMD CMD.bin -newflags\n" >CMD
+x CMD

I count 9 of those usages in my /usr/bin dir.  Only 3 of them
are ones I added, the rest are added by distro's to re-invent
Env vars.

Those are a sample of a new nightmare being created by the
ENV-var/config-file naysayers -- a far more toxic solution IMO,
as they aren't centralized.

Perhaps centralizing, at least for linux, would be using
an overlay file system on top of existing binary directories
that overlay shell scripts on top of binaries that don't
allow defaults to be configured with them calling the
real binaries via a hidden path (/usr/.bin/...).  That might
almost be reasonable, but certainly a pain, since there's
no way to reliable get at the real binary.

But such is the legacy of removing ENV vars to allow defaults --
even if those are limited to interactive execution.

Linda