|
From: | Linda Walsh |
Subject: | bug#16282: revisit; reasoning for not using ENV vars to provide workarounds for POSIX limitations? |
Date: | Sun, 29 Dec 2013 09:07:59 -0800 |
User-agent: | Thunderbird |
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).
[Prev in Thread] | Current Thread | [Next in Thread] |