bug#16282: revisit; reasoning for not using ENV vars to provide workarounds for POSIX limitations?

[Linda Walsh]

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).