"After that I developed the habit of double checking what I'm about to do on the Linux command line before pressing Enter," Wilma wrote. "Because as I learned, Linux will do what you said to do and it WON'T ask if you are sure."

Where there's a Wilma there's a way

She had to Yabba Dabba Do it

Honey, I'm ~

You're such a good localhost

... where's Fred?

They're having a barney.

She told you all you needed to know ... the student association's webserver was Fred, the Fucking Ridiculous Electronic Device.

Wilma was extremely lucky that there were backups of the other web sites, but her first mistake was to begin by DELETING the old web site directory, when a more experienced person would have RENAMED the directory e.g. "mv website website.old", before installing the new web site alongside it. That way, if the new version didn't actually work in the production environment, the old web site could be restored in seconds with a couple of directory renames.

Still, the wise learn by their mistakes.

And then there will be

website.old

website.older

website.old_v2

website.old_v4

website.old_v4_new

The location of website.old_v3 is a mystery to this day

v3 has the directory named website.even_older, which you did not see in your list since you used "website.old*".

I seriously have files named "...even-olderest-but-not-quite..." in some folders somewhere.

and website.old.temp

and website.old_v2 (copy) that isn't a copy.

Use:

ls -al --full-time

or equivalent for your particular *nix.

After long and painful struggle with versions of ".old" I now use the decommission date ".old_[yyyymmdd]". So, no one would even notice if there's .old_v3 missing.

Her first mistake was agreeing to work on a live webserver for no pay.

Only a fool learns from their mistakes. The wise learn from others' mistakes.

I'd say a fool doesn't learn from their mistakes.

I don't rename, I make a zip

$ zip -r website-2025-09-15.zip website

I like using zip on Unix since its a format that windows users think they understand.

Works pretty much everywhere except these new-fangled containers...

Takes less space than a rename.

So I have zips littered over my filesystem with various datestamps.

And I still have to delete afterwards, so the terror is still part of the process...

"I like using zip on Unix since its a format that windows users think they understand."

But you lose all of the ownership and permissions metadata. Real UNIX admins use tar.

My "why did Wilma have the rights to delete all that" alarm goes off. She should only have had write/delete rights to the one website she was supposed to update. A failure one step above, IMHO. And they should have implemented RBAC after that incident.

Though a few (20+) years back my mind was not so picky about who has which rights to prevent any disturbance of the infrastructure. Some things you learn along the reality. The university should have had that in place, but I know how it was "back then". Doesn't mean they are better now, but it should.

It's a university. They don't have the time, nor the inclination, to do proper profile security.

You need to work on that server ? Fine. Here, you have admin rights on everything. If you foul up, it's not my fault.

1) Type the command but do not press

2) Take you hands away from the keyboard

3) Use your finger to point at each part of the command and check it's what you thought you had typed

4) Verify that you are where you are supposed to be

5) Commit the command

Also works with critical GUI-based activities, where you physically point at the various settings as you check them all.

People may think you look like a mad person, but that's much better than making a mistake.

I suggest step 4 should be step 1.

I once learned the hard way that ' -r .*' in linux includes ../, and will apply to the whole file system. Especially nasty when you use sudo on a multi user system.

After that, and a few other near-disasters with rm, I decided to precede every

rm

with executing

ls

And look at the output. Only then will I change 'ls' to 'rm' (or chmod).

And I also removed 'rm' from the history command, just to be sure, in ~/.bashrc:

export HISTIGNORE="rm*"

Also, add to your .bashrc:

alias rm='rm -i'

I do the same with any significant changes in the SQL data, and generally put the update or delete commands as comments so I have to manually select the code to execute it

SELECT xxx FROM yyy WHERE zzz

/*

UPDATE yyy SET aaa = bbb WHERE zzz

*/

Of course the very fact this forces me to think about what I'm typing generally prevents mistakes but just occasionally it saves me, usually 'cause there's something I've missed in the WHERE statement.

I thought the whole "* includes../" thing was fixed now? Otherwise my machine would have been empty many times over!

But I'd be thinking of Wilma.

This is crazy. We're talking about going to bed with Wilma Flintstone.

You're right. We're nuts. This is an insane conversation.

She'll never leave Fred, and we know it.

Unix had to save some paper and tape, after all prompts where bad on a teletype.

The problem is Linux still lives in that era, and can't grow up.

I'm working on a Blazor app that clears a directory before users put files in it . The directory varies depending on circumstance and it picks up the location from its a database.

The other day ( in the development environment ) that filepath failed to come through so the app decided instead to just start deleting its OWN location!

It munched through the first layer of its source code in a sort of suicide attempt .

luckily the delete didn't include subfolders.

Being the sole authorI have only myself to blame.

Be very careful with mirror copy commands .

Your filepaths must be exactly right other wise folders won't match and be deemed "superfluous"

I once destroyed a colleagues windows\system32 folder this way while trying to push some files to his laptop