bug#16282: revisit; reasoning for not using ENV vars to provide workarounds for POSIX limitations?
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).
bug#16287: RFE rm -x == --one-file-system
Would it be possible to let rm have a -x flag to be consistent with other utils that use -x to mean --one-file-system? It seems to be a widespread convention.
bug#16287: RFE rm -x == --one-file-system
On 12/29/2013 06:10 PM, Linda Walsh wrote: Would it be possible to let rm have a -x flag to be consistent with other utils that use -x to mean --one-file-system? It seems to be a widespread convention. Thanks for the suggestion. However, although -x is indeed a common option of several programs, we are reluctant to add new short options. I'd only consider doing so for compatibility reasons if there would already exist an implementation of 'rm -x'. I didn't find any ... apart from 'srm' [1] which even has a different program name. Do you know any other? [1] http://srm.sourceforge.net/ Have a nice day, Berny
bug#16287: RFE rm -x == --one-file-system
Bernhard Voelker wrote: On 12/29/2013 06:10 PM, Linda Walsh wrote: Would it be possible to let rm have a -x flag to be consistent with other utils that use -x to mean --one-file-system? It seems to be a widespread convention. Thanks for the suggestion. However, although -x is indeed a common option of several programs, we are reluctant to add new short options. I'd only consider doing so for compatibility reasons I'm looking at compatibility reasons with coreutil programs that recurse directories. More important that other implementations, would be an expectation of similar switch options within one distribution of these programs. Of the core utils that recurse directories, only chgrp does not have an option to stay on the current file system. All of the other *recursive* core utils that have the ability to isolate action to 1 file system have -x. chmod, cp, df, ls, dir, du find uses -xdev tar uses -x secure rm (srm) uses -x mkzftree uses -x (makes a zisofs) primarily was thinking about consistency in the coreutils -- for that matter, chgrp should probably follow suit in providing the ability to stay on 1 fs, and -x as it's the only recursive utils that doesn't provide that ability. As you mention the only other 'rm' util secure rm, also provides -x. Suppose you didn't put it to use to mean what all those other utilities use it for. How could would it be if it took on some completely different (and perhaps cross-purpose) meaning? Wouldn't consistency among those tools that have recursive options be desirable?
