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://listman.redhat.com/archives/fedora-devel-list/attachments/20060121/b29fa61d/attachment.sig>


More information about the fedora-devel-list mailing list