GNU bug report logs - #16287
rm: add "-x" option alias for --one-file-system

Previous Next

Package: coreutils;

Reported by: Linda Walsh <coreutils <at> tlinx.org>

Date: Sun, 29 Dec 2013 17:12:01 UTC

Severity: wishlist

To reply to this bug, email your comments to 16287 AT debbugs.gnu.org.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#16287; Package coreutils. (Sun, 29 Dec 2013 17:12:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Linda Walsh <coreutils <at> tlinx.org>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Sun, 29 Dec 2013 17:12:02 GMT) Full text and rfc822 format available.

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: RFE rm "-x" == "--one-file-system"
Date: Sun, 29 Dec 2013 09:10:52 -0800
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.





Information forwarded to bug-coreutils <at> gnu.org:
bug#16287; Package coreutils. (Mon, 30 Dec 2013 00:28:02 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Linda Walsh <coreutils <at> tlinx.org>, 16287 <at> debbugs.gnu.org
Subject: Re: bug#16287: RFE rm "-x" == "--one-file-system"
Date: Mon, 30 Dec 2013 01:27:39 +0100
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




Information forwarded to bug-coreutils <at> gnu.org:
bug#16287; Package coreutils. (Mon, 30 Dec 2013 01:18:02 GMT) Full text and rfc822 format available.

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

From: Linda Walsh <coreutils <at> tlinx.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 16287 <at> debbugs.gnu.org
Subject: Re: bug#16287: RFE rm "-x" == "--one-file-system"
Date: Sun, 29 Dec 2013 17:17:18 -0800

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?






Information forwarded to bug-coreutils <at> gnu.org:
bug#16287; Package coreutils. (Mon, 30 Dec 2013 09:43:02 GMT) Full text and rfc822 format available.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 16287 <at> debbugs.gnu.org
Subject: Re: bug#16287: RFE rm "-x" == "--one-file-system"
Date: Mon, 30 Dec 2013 10:42:42 +0100
On 12/30/2013 02:17 AM, Linda Walsh wrote:
> Bernhard Voelker wrote:
>> 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.


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

Stop, stop, stop.
This is not an 'which program has a -x option?' contest.

Some of the above programs don't even have a -x or
--one-file-system option (e.g. chmod) while others have
a -x option, but that don't stand for --one-file-system
(e.g. df and ls); and finally, some are not even part of
coreutils package (e.g. tar).

To stick to your argument - "compatibility" among coreutils programs -
here is a little list:

* These coreutils programs have a -x option (with mostly a
  completely different meaning, of course):

    cp df du ls od shred stty test

* These coreutils programs have a --recursive option:

    chcon chgrp chmod chown cp ls rm

* These coreutils programs have a --one-file-system option:

    cp du rm

So even with that more accurate table, this is a quite weak
argument to add "rm -x".

What I meant (and I thought that would be obvious): I wanted
to know if there are other 'rm' implementations which have
the -x option - the *BSDs, Solaris, etc.

Have a nice day,
Berny




Information forwarded to bug-coreutils <at> gnu.org:
bug#16287; Package coreutils. (Mon, 30 Dec 2013 18:08:01 GMT) Full text and rfc822 format available.

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

From: Linda Walsh <coreutils <at> tlinx.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 16287 <at> debbugs.gnu.org
Subject: Re: bug#16287: RFE rm "-x" == "--one-file-system"
Date: Mon, 30 Dec 2013 10:06:59 -0800

Bernhard Voelker wrote:

> * These coreutils programs have a --one-file-system option:
> 
>     cp du rm
-----

Guess I got a bit carried away.

On the above list with --one-file-system, only 'rm'
is missing -x as a shorthand for it.

I don't know that either BSD or Solaris have a
one-file-system option, so it seems unlikely they would
have a -x.

secure rm does have -x, which has the same meaning.

You can create any arbitrary set of conditions that
fulfill your need for acceptance or denial.

tar also uses -x and find uses -xdev.

Clearly there are 4 other utils that use -x to
mean stay on this file-system with -xdev being a weak
fifth since find doesn't have many (if any) "--long"
options.





Severity set to 'wishlist' from 'normal' Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Fri, 19 Oct 2018 23:29:02 GMT) Full text and rfc822 format available.

Changed bug title to 'rm: add "-x" option alias for --one-file-system' from 'RFE rm "-x" == "--one-file-system"' Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Fri, 19 Oct 2018 23:29:02 GMT) Full text and rfc822 format available.

This bug report was last modified 6 years and 240 days ago.

Previous Next


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