Can anyone explain that? I could imagine someone might invent a shell where ~* expands into a list of everyone's home directory, but I've never heard of that

Doesn't make sense does it? ~* is nothing, ~/* is everything in the current user's home directory.

I can't think of any variations where that might be everything in everyone's home directory.

tcsh quirk, maybe. Haven't used anything other than bash for donkeys' years, so wouldn't know

rm -fr ~/..

If it's a tcsh quirk, it has been changed since the events recounted here:

$ tcsh -c 'echo ~*'

Unknown user: *.

~X would expand to the home directory of user X.

Whilst I was a big fan of tcsh in my early unix days I was unaware that ~* expanded to all users home directories. Seems a very odd thing to implement and struggling to think of a good use for it.

And of course emacs can be taught to look after its backup files all on its own.

Quoting the original article: Emacs backup files

emacs appends ~ to the filename when creating backup files.

$ cd .emacs.d

$ ls *~

bbdb~ gnus.el~ viper~ vm.el~

"cut his computing teeth on the Commodore C64"

No one raised on an Atari 400 would ever fall for that!

[Grabbing my coat and exiting stage left to avoid the incoming debris :D ]

BBC Micro for the win!

It's a bit like this [1]old BOFH

[1] https://www.theregister.com/2006/02/24/bofh_2006_episode_8/

Most, if not all of us, have had to learn a lesson about rm -rf and/or backups. But intentionally deleting automatic backups is probably the boldest move i've heard of yet!

Also good thing the sysadmin had proper backups, otherwise he would've been the one in on call/who me? retelling this story!

I had a data scientist call me in a panic as he had an "urgent" report and he'd lost his code. I pottered over and found that it was under version control which made me think it'd be easy - turns out he'd not pushed a commit in six months...

I showed him how to access the nightly snapshots and was suitably rewarded -->

But intentionally deleting automatic backups is probably the boldest move i've heard of yet!

I don't think these really count as backups, but whenever you modify and save a file in emacs, it saves a copy of the previous version in a file of the same name with a "~" suffix. So you end up with a lot of files called input.txt~, code.cc~, index.html~ and the like, which tend to clutter your directory. It's not a big deal, but it tends to be forgotten with time, so I see now that I still have in my home directory a file called blo~ created in June 2023.

I don't really rely on this feature, though it must have happened a couple of times in the past 29 years that I was useful. But at some point I was sufficiently annoyed that I created an alias to delete all of them more safely than typing "rm *~" with three paranoid checks that I don't have a space in the middle.

Every night, the AS/400 operator picked a new tape, stuffed it into the tape slot, and overnight the AS/400 performed a system backup.

This went on for years......

Then one weekend the AS/400 was replaced with a bigger, better model. The upgrade crew need to do some restoring, so they reached for the latest backup tape.

Ha! Corrupt! ...and so were all the other tapes in the cycle!

No one had ever tested a restore!!!!

....and I still wonder how many systems have backups which have never been tested. Someone out there might be able to tell me.

I still wonder how many systems have backups which have never been tested.

Any company run by Beancounters, so every publicly listed company in effect.

"What? You want to spend money testing that the Backups actually work? Dont be silly, of course they work. We don't waste money on such frivolous things! Now if you don't mind, the CEO has decided we need to move the Logo on the corporate letterhead to the other side of the page. So I have to organise a budget to get a new design for the corporate letterhead made, get an external printers to start printing the new letterheads in bulk, and hire another firm to dispose of all of our unused current stock. So please go away, I'm busy."

Cynical, Moi?

If the backup hasn't been properly tested, it's not a backup. At best, it might be a copy of whatever you thought you were backing up.

I managed to screw up my OPNSense firewall at the weekend, luckily I had configuration backups saved which meant I didn't have to create the VLANs and firewall rules from zero.

The only problem was that they had an old PiHole IP address and it took me ages to figure out why I couldn't access the Internet (see icon)

As a friend of mine used to say

``Restore ? Restore ? Noone said anything about restore. Alll you wanted was backups.""

Well, speaking as an old f4rt and someone who is heavily into backups, surely if someone is responsible for changing the tapes (or nowadays checking on the backup storage utilisation or data crystals or whatever the storage du jour is), then they should take the initiative and responsibility to also wonder, "What would happen if we needed to recover some data? Or a system?"

Build regular recovery testing into the job and make it official. And when it becomes official, it will simply slide into your monthly tasks along with your other checks.

It doesn't have to be exhaustive and put in the procedures - yes, write procedures! have a checklist! have a record of what has been recovered and when! - a disclaimer that these are just quick recovery tests and no guarantees can be given to recover all data possible and that there is no gaurantee that the contents won't be corrupt without proper testing. With regular recovery testing of the various objects (e.g. files, databases, individual e-mails, AD objects, complete VMs, etc.) that you back up, then when the time comes you will either know exactly what to do and quickly get the system back or it will fail spectacularly. In which case, point to all the previously successful recovery tests and the disclaimer and say "I did my best, but without management buy-in to test properly, there's nothing else I can do."

That he alleged to have used to create the WWW Is on display at CERN. Quite a good family day out, if you're in Geneva and have some time to spare. We didn't get to see the tunnels when we visited, because they weren't open that day, but we did get to see the control room. (Catch the tram out from the city centre, and when you get there, make sure you get yourself booked on to a tour before they fill up for the day.)

Also worth visiting is the Diamond Light Source near oxford, which does open days, and is (kind of) the same thing on a much smaller scale.

Not far from CERN is the [1]Musée Bolo in the EPFL Campus at Lausanne . It's free to enter and has lots of nice toys ranging from home computers to bits of massive supercomputers.

[1] https://www.museebolo.ch/en/

"....and I still wonder how many systems have backups which have never been tested. Someone out there might be able to tell me."

A lot, lot more systems than you would like to might imagine. :(

Working in an institutions where "fat fingers" are the rule rather than the exception usually means the backups are frequently "tested."

Archives weren't routinely tested even during thekr nominal retention period. Since migration of older archives to current media and tech wasn't a thing most archives ceased to have the means to be read before anyone could determine whether they were unreadable.

You can get lucky though - I have had a complete restoration of archives from a DDS2 (DAT) tape ~15 years after they were made (the drive pulled out of the junk pile.)

Hint: don't use vendor backup/dump utiities (eg vdump, vxdump or even xfs_dump) for archives as there is a good chance you won' t have a system (tru64, hpux, sgi) to be able to read them. Gnu tar (or cpio) has served me well here. You cannot expect to have good fortune of [1]vmsbackup where someone once created a compatible tool. (I once made one chap's day recovering his files from a very old vax vms dump tape. I didn't even laugh when he asked whether we had a vms system with a tape drive. :)

[1] https://github.com/DaveShepperd/vmsbackup

The power of the rm -rf command.

You're not a real unix/linux sysadmin until you have issued it in the wrong place and had to feel how powerful that command is.

Not sure why "Miles" got a slap on the wrist. At worst all he should have been able to do is empty his own home directory, and have no-one to blame but himself. But the error that allowed deletion of everyone else's files is entirely the sysadmin's responsibility.

Exactly this.

this all happened in the 90's, last century in new speak.

the admin didn't know he needed to tighten things to prevent incidents like this.

once it became apparent, the admin applied the appropriate controls.

Why were the "appropriate controls" in existence if not needed?

User permission management wasn't some new concept introduced in the 90s.

My first "real" job was as a university sysadmin, it was in a Physics department, and the computers were NeXTStations, with a couple of cubes, and a couple of OPENSTEP PCs (and then a massive Solaris server because NeXT had already disappeared by then). My first "real" mistake was getting the arguments to tar the wrong way around, and writing an empty hard disk to our master image tape instead of writing the master image to an empty hard disk. Luckily, there was a backup of the tape…