[Bug 448122] Review Request: trash-cli - Command line trashcan (recycle bin) interface

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: trash-cli - Command line trashcan (recycle bin) interface


https://bugzilla.redhat.com/show_bug.cgi?id=448122





------- Additional Comments From pertusus at free.fr  2008-06-25 03:41 EST -------
(In reply to comment #12)
> (In reply to comment #11)
> > Unlike your "trash" application, these applications are ISO/IEEE/POSIX
> > standardized, widely used and have a long (25+ years) history.
> "lsmod" is not so old and is not called lsmod-cli, its name reflet what it does
> (list the modules). Is "lsmod" ISO, IEEE or POSIX standardized?

lsmod is specific enough.

> The "rename" command present in the Fedora is called "rename", not
> "yet-another-renamer", the rename command is not so old nor standardized. In

It is in util-linux-ng, so this is not something very problematic, it 
is going to be a defacto standard.

> fact the "rename" found in other distribution is from a different package with
> another interface. 

That's an issue, but I'd say that in that case the rename from util-linux-ng
should be considerd as the reference. I may be wrong, I don't know this
very well.

There are other better example, however, ren is such an example, and it
is my bad since I reviewed and accepted it, certainly before Ralf made me
aware of the naming issues. Another example is GMT, but in that case I think
that it has enough precedence since this application is very old.


> Instead the trash-cli package will be present soon in at least two distribution
> (Fedora and Ubuntu) with the same command names. 

That's not a good reason.

> Another not so old example are "lspci" that list the PCI devices.

But this is not a non-specific name.

> In my opinion each command name should reflect what the command does. 

As far as possible.

> > That said, I agree with comment #1, upstream should consider to rename their
> > "trash" application into something less generic.
> There is not a "trash" *application* there is a package named "trash-cli" that
> provides four commands (implemented as executables):
>  - trash (that trashes files)
>  - list-trash (that list the trashed files)
>  - empty-trash (that empty the trashcan(s))
>  - restore-trash (that restore a trashed file)
> 
> You think that I should rename all adding -cli?

No, only trash in my opinion. The others are specific enough. They could 
be even more specific, but at the expense of usability. The right level 
of non-genericity is something subjective, my feeling is that 
trash is not right since it may clash easily with an application doing something
very different, and be used in a standard in the future, be
is a defacto standard like what is in some basic package like util-linux,
coreutils, bash buil-in and a few others or a real standard.

> The Freedesktop Trash Specification are followed by KDE, soon by GNOME, and by
> other Desktop Enviroment. 
> I think is enough a standard that name the command line interface commands to
> interact with it without adding some strange suffix.

The command name is not standardised, isn't it? Not the command line
interface? If it is so, then the alternative system should be used, 
but I don't think this is the case here.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.