libtrash in fedora Core 5
Lamont R. Peterson
lamont at gurulabs.com
Sat Jan 21 19:34:27 UTC 2006
On Saturday 21 January 2006 11:14am, Jeff Spaleta wrote:
> On 1/21/06, Ola Thoresen <redhat at olen.net> wrote:
> > My point is that if we want this kind of feature, it should be
> > trasparent to the user (like libtrash) so you don't have to rewrite a
> > gazillion scripts and alter user behaviur.
>
> I really really think its a bad idea to change the behavior of the rm
> command to meet the expectations of desktop users, who drop to the
> commandline. rm's default functionality of deleting files should not
> change. libtrash is a hack, which should be applied by people who know
> that they want to apply that hack and should not be something that
> drops in and automatically reconfigures the functionality of rm. How
> many shell scripts exist which rely on standard rm functionality?
I agree; especially because of shell scripts.
Here is my thought on how to introduce the capability sanely: Create a new
command ("trash" or "toss" or something-else?) that one would use instead of
rm. That command would look at the configuration found
in /etc/something.conf (you know, that matches the name of the command) or an
environment variable (probably a much better choice for performance) and
will: "mv" files to a designated directory on the partition/volume (like
"/.thetrash/".
When a file is moved to the trash, an entry should be placed in a file in the
trash directory (like ...where_this_trash_came_from) that looks like:
"trashed-file" "/full/path/to/where/it/came/from"
That would make a "recover" ("untoss"?, "reinstate"?, whatever) command very
easy to implement.
Then, add the option (and have it on by default) to both Nautilus & Konqueror
to use this trash mechanism instead of their own, separate ones. That way,
for users who want to do this on the command line, they can go back and forth
between the command line and either desktop environment. Adding this to
other desktop environments would also be easy.
We *could* look at adding the capability to the rm command itself (or simply
alias rm="toss"), making sure that:
1. Only use the capability if the central .conf file or user's ~/.tossrc file
has the option turned on to use it.
2. Only mv files automatically that are smaller than a certain threshold
(configured in the .conf or the ~/.tossrc file?).
3. Possibly display a message (once per invocation of "rm") telling the user
that there is this new-fangled trash capability, unless the .conf or
~/.tossrc file has the "supress that annoying thing" option flipped on.
Adding this to rm (or via an alias to toss that causes it to behave for the
way rm would) will let those who want it to always happen no matter what have
it their way. In this case, using rm on a file in the /.thetrash/ directory
would actually unlink it.
Well, that's just off the top of my head. I think the key is that "rm" should
not change behavior (other than perhaps to let people know that it can)
unless a user chooses to make the change, that the new command be short (the
name, which is why I kindad like "toss") and easy to use (uses the same
switches as rm, perhaps?) and it should be uniform across all the UI's where
users might like to have it.
Personally, I would not turn on the "rm actually moves to trash" feature,
ever. But, I can understand that there are people who would.
I think this idea is a good compromise, bringing a useful feature to Linux
without borking the way things work. I would be perfectly happy to write it,
but I want some feedback from you folks, first. Have I missed something that
you think is needed, here?
Thanks.
--
Lamont R. Peterson <lamont at gurulabs.com>
Senior Instructor
Guru Labs, L.C. [ http://www.GuruLabs.com/ ]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20060121/b29fa61d/attachment-0002.bin
More information about the devel
mailing list