GNU bug report logs - #16282
revisit; reasoning for not using ENV vars to provide workarounds for POSIX limitations?

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16282 in the body.
You can then email your comments to 16282 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: revisit;
 reasoning for not using ENV vars to provide workarounds for POSIX
 limitations?
Date: Sat, 28 Dec 2013 10:37:54 -0800

I didn't fully  understand the reasoning for not wanting ENV vars to override
unwanted behaviors.

Specifically, I'm thinking about "rm -fr .", but there are some others it could
apply to as well.

ENV vars are used to configure all sorta of GNU utils -- so why the reluctance
to do so in order to provide backwards compatibility in overcoming prescribed
limitations imposed by POSIX?

It's not like it's impossible to create ENV vars that are unlikely to collide with
normal ENV var usage, i.e. _rm::EXPERT=allow_dot[,..other features].

Adding colons to the middle of the env var, should both, prevent any accidental
setting/usage of such as well as making such overrides easy to find and filter
on (if all included '::' after the util name, for example and all started with _ --
they would tend to collate together and the '::' would likely be unique enough
to filter on in a grep'ing of the environment.

If the issue was accident setting or collision with other usage, something
like that would seem to address that problem.   If there are other issues,
I'm not aware of them...

Thanks for any input...

Message #8 received at 16282 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Linda Walsh <coreutils <at> tlinx.org>, 16282 <at> debbugs.gnu.org
Subject: Re: bug#16282: revisit; reasoning for not using ENV vars to provide
 workarounds for POSIX limitations?
Date: Sat, 28 Dec 2013 12:03:20 -0800

Linda Walsh wrote:
> Adding colons to the middle of the env var

That would make the var impossible to use from the shell.

And no matter what the name is, if it makes a standard
utility behave in odd ways, it'll break scripts that
don't expect the odd behavior.  That's the essential
objection here.

Yes, we've used env vars in the past for this, but we've
come to regret it, and we don't want to make matters worse
in this respect without a compelling justification.

Message #11 received at 16282 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 16282 <at> debbugs.gnu.org
Subject: Re: bug#16282: revisit;
 reasoning for not using ENV vars to provide workarounds for POSIX
 limitations?
Date: Sat, 28 Dec 2013 16:00:48 -0800

Paul Eggert wrote:
> Linda Walsh wrote:
> > Adding colons to the middle of the env var
>
> That would make the var impossible to use from the shell.
----
That's what I thought you'd say -- meaning it would be well protected
against accidental usage.

However:

> env foobar::snore=1 |grep ::
foobar::snore=1

>
> And no matter what the name is, if it makes a standard
> utility behave in odd ways, it'll break scripts that
> don't expect the odd behavior.  That's the essential
> objection here.
----
Having "rm -fr ." not follow historical depth-first behavior and,
out of sequence, check for a . is "odd behavior".

That's the essential objection -- and I'm trying to get back
the original behavior -- not ask for some new behavior.

Message #14 received at 16282 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 16282 <at> debbugs.gnu.org
Subject: Re: bug#16282: revisit;
 reasoning for not using ENV vars to provide workarounds for
 POSIX	limitations?
Date: Sun, 29 Dec 2013 09:07:59 -0800

Linda Walsh wrote:
>> And no matter what the name is, if it makes a standard
>> utility behave in odd ways, it'll break scripts that
>> don't expect the odd behavior.  That's the essential
>> objection here.
> ----
> Having "rm -fr ." not follow historical depth-first behavior and,
> out of sequence, check for a . is "odd behavior".
> 
> That's the essential objection -- and I'm trying to get back
> the original behavior -- not ask for some new behavior.
--

The other alternative to this (which I'm not adverse to)
would be reading a system "rc" (and/or) a per-user "rc"
config file that allows or disables various behaviors.

Specifically, "rm" had both "-i" and "-I" to give
different levels of prompting that could be put in an
alias.  It also had "-f", "--force" that were supposed
to force never prompting, and do what it could -- that
extra switch was supposed to override such a check but
was hamstrung -- yet it was specifically designed to
circumvent the errors it could and be silent about it.

Maybe cp -ffr to doubly force it?...

Given the addition of "-i" "-I" and "-f" and over the
years, it *seems* like this issue has ping-pong back
and forth between those who want to disable such
functionality and those who want it.  Only site
wide or per-user configurability of the command via
.rc or ENV vars would seem to offer both sides what
they want.  To claim that ENV vars always cause
trouble seems myopic at best and just ignoring a
long standing issue inviting custom versions that
will allow no trackability of what is in effect.

At least with ENV ops, they can be captured in
an ENV snapshot or test (less likely so, config
files).

Message #17 received at 16282 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Linda Walsh <coreutils <at> tlinx.org>, 16282 <at> debbugs.gnu.org
Subject: Re: bug#16282: revisit; reasoning for not using ENV vars to provide
 workarounds for POSIX limitations?
Date: Thu, 17 Jan 2019 23:16:12 -0700

severity 16282 wishlist
tags 16282 wontfix
close 16282
stop


(triaging old bugs)

Hello,

On 2013-12-28 1:03 p.m., Paul Eggert wrote:
> [...] if it makes a standard
> utility behave in odd ways, it'll break scripts that
> don't expect the odd behavior.  That's the essential
> objection here.
> 
> Yes, we've used env vars in the past for this, but we've
> come to regret it, and we don't want to make matters worse
> in this respect without a compelling justification.

Given the above, and with no further comments in 5 years,
I'm closing this bug.

More details about the reasoning for rejecting new environment variables
are summarized here:
  https://www.gnu.org/software/coreutils/rejected_requests.html#envvar

regards,
 - assaf

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.