Today's article is even more fun with the rm command!

[KGIII]

I wrote an article about making the rm command a little safer. It was poorly understood, but that's fine. This article is even more fun with the rm command.

I tried to make this one as simple as possible. I'd say it's more advanced and only a more advanced user should try it - but that's not true. If you just follow the directions exactly was written (I hope!) it should work. You may have to do some digging and you may have to verify that the path is correct (if you don't already know the path).

Let's Make The rm Command Even Safer • Linux Tips

Today's article is one I don't expect most folks to follow, but it'll be a fun way to make the rm command even safer.

linux-tips.us

So, we made the rm command a little safer. Now, we can make the rm command even safer! I suppose it'd be possible to do both but I didn't waste any energy thinking about that.

This is posted a bit late 'cause of Mother Nature.

 

[osprey]

The problem I had with the following code:

#rm to trash function
rm_to_trash () {
mv "$@" ~/.local/share/Trash/files
}
 
#rm alias
alias rm='rm_to_trash'

is that the file that was being removed by the alias: rm, ended up renamed as "files" in the ~/.local/share/Trash/ directory. This meant that the file that was being removed, had its contents placed in the file named "files", rather than having its original name with its original contents moved to the ~/.local/share/Trash/ directory.

As a consequence, any file that is removed through the use of the function and alias, replaces the file named "files", so there is only ever one file in the ~/.local/share/Trash/ directory called "files" with the contents of the last removed file.

Usually, I suppose, the user would prefer the removed files to retain their own name, and also accumulate in the Trash directory. That can be accomplished by removing the file "files" from the function, or by ensuring that "files" is a pre-existing directory, and then the removed files will gather in a directory for the user to inspect at will.

 

[KGIII]

Hmm... I tested it on Lubuntu and Mint and files removed with the command retain their own name in the /files directory.

Let me check that again.

 

[KGIII]

That's on Mint which is what I'm using at the moment.

I created two files (garbanzo and foo) and then used the 'rm' command (aliased to the function) and it placed them happily within the /files directory.

#rm to trash function
rm_to_trash () {
mv "$@" ~/.local/share/Trash/files
}

#rm alias
alias rm='rm_to_trash'

Is the code in use.

Do you have some weird other aliases messing around with it? Do you have some odd function that's messing with it?

It works exactly as intended here - on two distinct systems. What distro are you using?

 

[KGIII]

Oh, wait... You mean if you remove another file with the same name?

Yeah, you're boned. It's a one shot deal. It's not perfection, it's a bit safer than the rm command by itself.

If you remove two files with the same name, you're gonna lose the first one. Don't do that. Don't make the same mistake twice. I can't really stop the user from doing that. I suppose I could do some sort of incrementation, but I'm not gonna do that.

 

[osprey]

The problem I had was at first not creating ~/.local/share/Trash/files/, where "files" was a directory. I just copied the code, and since there was no slash after "files", the mv command interpreted "files" as a filename. It wasn't clear to me on reading the article that "files" was a directory. If the reader saw it as a directory on first reading, there would be no problem, so I can attribute the problem I had to my reading of it.

 

[KGIII]

The problem I had was at first not creating ~/.local/share/Trash/files/, where "files" was a directory.

What distro are you using? In my case, the directory already exists.

Let me check something... Give me 10 minutes.

 

[osprey]

It's a debian machine running Trixie. The directory needed to be created.

 

[KGIII]

Ha! I think I solved it!

So the directory ~/.local/share/Trash/files doesn't exist until after you have moved something to the trash.

Until then, on a clean installation, it simply doesn't exist. Until you take a file and delete it, you have no trash folder.

Had you not previously deleted anything, sending it to the trash bin?

If not, that explains everything. That's a simple article edit.

 

[KGIII]

And the article is updated. Thanks! That appears to resolve it.

You either need to manually create the directory or have previously moved something to the trash. If you haven't done so, the directory simply doesn't exist. I move crap to the trash all the time, so I've never noticed this.

(Edit: I forgot to smash the like button in my haste. In my defense, it made me pretty occupied.)

 

[osprey]

Another aspect that came to mind is that if the function itself is named "rm", then the alias wouldn't be required and it would all work as intended in any bash shell system. There may however, be reasons to keep the functions and aliases apart.

 

[KGIII]

Another aspect that came to mind is that if the function itself is named "rm", then the alias wouldn't be required and it would all work as intended in any bash shell system. There may however, be reasons to keep the functions and aliases apart.

That's an interesting idea. I am not sure where the terminal will look first - but it'd probably be the .bashrc file (and profile, and alias) first. So, that might work. I haven't tested that one. It's worth testing, I suppose. At least then I'll know which is checked first.

But, I'd definitely not do that - just in case. I'd rather name the function and then use an alias. There's probably some edge case where it'd screw up.

I should probably have mentioned that it's also possible to escape the alias. If you don't want to send the files to the trash bin you can just do \rm <foo>.

Anyhow, I edited the article last night. I placed more information after the, "You should verify this and change the path accordingly." sentence. I mean, I had kinda made a contingency statement, but that wasn't clear enough.

I had no idea that the directory just didn't exist until you moved something to the trash.

I don't know how many people would have even known that. My memory isn't great, but I don't recall anyone ever mentioning it. Had you not commented, I'd have never noticed. I did due diligence, I thought. I'd checked on not one, but two, different operating systems.

But, now we know! I doubt this is ever going to be an issue ever again. It just doesn't seem like it's going to be something that pops up again.

I should turn that into a short article. Though, it's probably not a question folks are going to ask and it's unlikely to be typed into a search engine.

Ah well...

Thanks again! We're now slightly wiser!