Today's article is a pretty easy article but perhaps an important step for some folks...

[KGIII]

Let's be real...

In inexperienced hands, the rm command can be risky business. I bang out rm commands all the time (when I'm trying to keep my file system organized, at least) and use it to good ends. But... Well, unless you're into file recovery, rm can be one of those tools that teach valuable lessons about things like typos. It's not forgiving.

But, you can make the rm command automatically include a sanity check. It's easy and something I'd probably recommend for new users who are going to go mucking about in the terminal. Heck, it might even be useful for us old graybeards...

Let's Make The rm Command A Little Safer • Linux Tips

Linux Tips helps you get your Linux skills up to speed, by making Linux approachable.

linux-tips.us

Yeah, it's a cheesy alias - but it's an effective alias. You're just adding the -i flag automatically, which means you'll see what will be removed and given a chance to back out of the operation.

And yes, I know, I still haven't done an article on aliases. I've started that article twice and I just can't think of a good way to write it while fitting in with the formula I've been using. So, it's an article that will be written. I just need to be a better writer than normal.

 

[BigBadBeef]

Don't do it... just don't!

sudo rm -rf /*​

 

[KGIII]

Yeah, it's probably a good idea to alias rm to rm -i, just to have the sanity check.

 

[osprey]

KGIII wrote:

...cheesy alias ....
....
Yeah, it's probably a good idea to alias rm to rm -i, just to have the sanity check.

High class cheese though

On the debian (and formerly fedora) installations that I've installed there's been a default for root in its .bashrc:

 alias rm='rm -i'
 alias cp='cp -i'
 alias mv='mv -i'

but not for the user. Users can choose their aliases of course, but for sys admin here these root defaults are included in the /etc/skel/.bashrc, so the user is "opted in", and has to opt out rather than the reverse.

 

[KGIII]

On the debian (and formerly fedora) installations that I've installed there's been a default for root in its .bashrc:

Yeah, that definitely makes sense for the root account. A user by themselves can really only trash their own data.

Hmm... I have another rm article that I'm wanting to write, but I'm not sure I should do two in a row. Though, I should probably write it before I forget it. I don't think it's in my notes anymore.

 

[BigBadBeef]

Alright, joke aside. It is my belief that your article is a bit of a paradox - those who understand the danger of rm will already be careful with it, but those who don't, likely won't bother taking heed of it.

 

[wizardfromoz]

David, I have not used the whack-a-mole button yet because you may need to add to the article.

Why? ^^^^^

If the files you seek to remove are in folders owned by Root, such as /bin /boot /dev /etc /usr /var and so on - you need to use sudo or assume Root with sudo -i (su and su - will return an Authentication Failure if you do not have a dedicated root password).

Sudo, however, will ignore your rm alias and just delete the files without asking for confirmation.

Try this if you like, to see what I mean, after setting up your alias and updating .bashrc.

sudo touch /etc/file1 /etc/file2 /etc/file3
ls /etc | grep -i file
#output
file1
file2
file3
profile
profile.d
tmpfiles.d
sudo rm /etc/file*
#executes without prompting for confirmation
ls /etc | grep -i file
profile
profile.d
tmpfiles.d

There are two ways I know of (probably more) to get around this.

1. is to get root access with sudo -i and then, as Root, put the same rm alias in its .bashrc, and then uodate .bashrc
Then sudo rm /etc/file* will issue the prompting for confirmation.

However that method will not "ripple through" if you return to Regular User and issue

sudo rm /etc/file*

2. Another method is to include an alias for sudo in the Regular User's .bashrc with the following (I have placed mine under the existing aliases)

# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'
alias rm='rm -i'
alias sudo='sudo '

Note that that is, within the quotes

sudo space

Cheers

Wizard

Edited 2nd line to make it clearer - Wizard

 

[wizardfromoz]

@BigBadBeef - I have just reordered and enhanced the post at #2 for just in case some silly sod types in the command before reading the warning.

Cheers

Wizard

 

[BigBadBeef]

@BigBadBeef - I have just reordered and enhanced the post at #2 for just in case some silly sod types in the command before reading the warning.

Cheers

Wizard

I bet there's some people trying it out right now, albeit in their virtual machines, just for the lols, to see the destruction take place.

I know KGIII's article is trying to keep them safe from that, but whomever doesn't understand the danger of "rm", probably won't follow his advice.

But if there ever was a rule of thumb for Linux users, then its that you do NOT just copy-paste code you don't know into the terminal!

 

[KGIII]

Why?

So that the user gets a second chance before removing their files. That's all it's about. Just that and nothing more.

That's why the article doesn't have sudo anywhere in it. It has nothing to do with removing files owned by another user.

If you're using sudo to remove your own files, you're doing it wrong.

Another method is to include an alias for sudo in the Regular User's .bashrc with the following (I have placed mine under the existing aliases)

I actually plan on doing an article about aliases, but every time I've tried to write the article it ended up a disjointed mess,

I know KGIII's article is trying to keep them safe from that, but whomever doesn't understand the danger of "rm", probably won't follow his advice.

Then that's their fault. They were given a chance to look this information up before running the rm command. That they failed to do so is hardly my fault, but the information is there for those who want it.

 

[dobeshow]

 

[BigBadBeef]

Then that's their fault. They were given a chance to look this information up before running the rm command. That they failed to do so is hardly my fault, but the information is there for those who want it.

Hehehe I like this attitude! People need to be made to understand that their obstinent ineptitude is not okay.

 

[KGIII]

Hehehe I like this attitude! People need to be made to understand that their obstinent ineptitude is not okay.

I have a similar article that I should write while it's on my mind. These things, as the title suggests, only make it a little safer. Nothing I could possibly write about would make the command completely safe when used by someone who doesn't understand what the outcome will be. Those folks wouldn't have read my article to begin with.

That's the thing with this command (and the rest, really). They do exactly what you tell them to do. If you don't tell them exactly what you want, you get unexpected results.

I've cautioned people many times about blindly running commands they find on the 'net. Take the time to read the man pages and make sure you know what that command is going to do before you run it.

Hmm... That should be the basis for another article.

 

[MikeWalsh]

@KGIII :-

Yeah. Well said, David.

Of course, you cannot make people read the man pages, etc, if they can't be bothered to. You can lead a horse to water.....but you cannot MAKE it drink.

What I've always liked about Linux is that the tools are there to allow the user to do literally whatever they want to.....but the onus is very much ON the user to learn about stuff before using it. You can only "hand-hold" people up to a point; beyond that, you're basically p***ing in the wind, because if they're determined to ignore the reams of good advice to be found on-line, then the outcome's on them.

In all conscience, they've got no come-back, and need to understand that they can't run crying to somebody else to "fix" things for them.

I lost track of the number of times I broke things in the early days, but then I've always learnt best by "doing"....

~~~~~~~~~~~~~~~~~~​

Linux is all about becoming self-sufficient with your system, and mastering it as thoroughly as you can so that you know what you can & can't do. Breaking it and having to re-install it a few times usually drives the mistakes home into the thickest of skulls. Notice I don't say ALWAYS.....but 99% of the time, people eventually get the message & learn from their mistakes.

There's always that 1% though.....


Mike.

 

[KGIII]

Breaking it and having to re-install it a few times usually drives the mistakes home into the thickest of skulls.

I call it "Learning By Breaking". I think it's a very viable way to gain an understanding of Linux.

I've suggested it quite regularly, specifically when someone asks how to best learn Linux. Learn to properly use a search engine and then start using the OS. Tweak things. Install things. Remove things. Customize things. Try all the settings.

You'll learn by mucking around with things and learn what settings shouldn't be mucked around with. You'll learn what's going on behind the scenes. If you're reasonably wise, you'll learn the importance of backups - and what files should be backed up.

I figure you're not going to learn to be a good mechanic by watching videos and reading documentation. You've got to get out there and get your hands dirty. It's all just theory until you've learned to use the tools and when to use specific tools. So, get your hands dirty and learn some Linux.

 

[wizardfromoz]

David, at #10

So that the user gets a second chance before removing their files. That's all it's about. Just that and nothing more.

That's why the article doesn't have sudo anywhere in it. It has nothing to do with removing files owned by another user.

it seems you have misunderstood what I started my #7 with. Let me clarify.

Where I said

David, I have not used the whack-a-mole button yet because you may need to add to the article.

Why?

...I was not referring to why on how you wrote your article.

Better would have been

David, I have not used the whack-a-mole button yet because you may need to add to the article.

Why? ^^^^

and I have now edited that. It was to do with why I had not yet hit the whack-a-mole, which you know I usually do, giving it a 4 or a 5 if it merits it IMO.

I have now edited my #7 to reflect that.

I am not a naysayer, and I did not misunderstand your article.

It could be remedied with a mere mention of eg

"This article relates to removal of files over which you the user have control, eg ~/home/<your-username>

HTH

Wizard

 

[KGIII]

"This article relates to removal of files over which you the user have control, eg ~/home/<your-username>

HTH

Ah, I see where you're going with that. Now I get you!

Hmm... I'll add something similar or just cut/paste and fit that in somewhere. In my head, it was obvious that it was only for your files. I suppose that might not be obvious.

That's one of the things that make writing all these so difficult (but helpful/educational for me). It's not easy to know what's obvious, what needs to be mentioned, what needs to be explained, what needs to be expanded, what words need to be defined, etc...

 

[KGIII]

Updated with this block of text:

NOTE: This article relates to the removal of files over which you the user have control, eg ~/home/<your-username>. If you're removing files with sudo, root, or as another user, the rm command will function as normal.

That should make it reasonably clear.