Red Hat Bugzilla – Bug 450850
Review Request: move - Move file(s) to ~/.trash directory
Last modified: 2008-07-25 06:40:03 EDT
SPEC URL: http://pjp.dgplug.org/tools/move.spec
SRPM URL: http://pjp.dgplug.org/tools/move-1.2-1.fc8.src.rpm
move moves the named file(s) to the ~/.trash directory. Trash is located
under the home directory of a user. It is a simple console based utility,
I wrote after deleting some files, which I couldn't retrieve back.
Move can also restore file(s) back to there original location. It has really
proved very handy to me.
This is my second fedora package, and am looking for a sponsor for this and my earlier package tlock. I'd really appreciate if somebody could come forward for the sponsorship.
1. I do not consider this application to be useful, because it aims at
implementing "yet another backing-up mv" replacement, using the "n-th"
2. Naming an application "move" is a bad choice, because it's such a general
name that it's likely colliding with many other applications/scripts users may
Provided this, I am not interested in formally reviewing this packages (This
shouldn't preventr others from doing so.).
Some technical remarks:
* The package doesn't acknowledge CFLAGS.
The cause is this bug in Makefile:
--- Makefile.am~ 2008-06-11 21:18:07.000000000 +0200
+++ Makefile.am 2008-06-11 21:18:07.000000000 +0200
@@ -11,7 +11,7 @@
## 6. automake -ac --foreign
-CFLAGS = -D_GNU_SOURCE
+AM_CPPFLAGS = -D_GNU_SOURCE
bin_PROGRAMS = move
move_SOURCES = move.c movedb.c move.h movedb.ham:
* The spec file uses /sbin/install-info
=> Missing: Requires(pre) etc.
Hello Ralf, thanks for the technical comments.
I've replaced CFLAGS with the AM_CFLAGS. Please see the new files at
> * The spec file uses /sbin/install-info
> => Missing: Requires(pre) etc.
About this Requires(pre), is it necessary if there is no %pre section in the
Well, now the package itself seems okay (althogh I recommend to use
make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p"
to keep timestamps on installed file), however I also think that
the name "move" is too generic...
Hello Mamoru, thanks for the comments.
I've made the changes. Please see the latest files at
> however I also think that the name "move" is too generic...
I do understand; But I really don't think it's practical to rename it..is it
that big a hurdle?
(In reply to comment #4)
> I do understand; But I really don't think it's practical to rename it..is it
> that big a hurdle?
Yes, it is. Did you approach upstream to ask them why they used such
a generic name?
> Yes, it is. Did you approach upstream to ask them why they used such
> a generic name?
Well, when I wrote Move it seemed like a sensible name, and it still does to
me. It speaks about it's action, and is intuitive that way. Why is it that big a
It is too generic. Many programs can do the same than yours, none should
be called move, except if there is a standard endorsing the name.
(In reply to comment #7)
> It is too generic. Many programs can do the same than yours, none should
> be called move, except if there is a standard endorsing the name.
What name would you suggest? Trash??
$ trash <file-name>
> What name would you suggest? Trash??
> $ trash <file-name>
I have a package (not yet reviewed) that already use
$ trash <file>
> I have a package (not yet reviewed) that already use
> $ trash <file>
Gawd...will ptrash do? I cann't believe I'm haggling for a name now.
ptrash would be perfect in my opinion.
Please see: https://bugzilla.redhat.com/show_bug.cgi?id=456385
*** This bug has been marked as a duplicate of 456385 ***