Keep backups of everything important. All development should take place in a version control system, and you should run any script on testing data first.

It might sound pedantic and tedious, but after accidents like yours, it all starts to make sense.

Also, don't blame Perl. It was you who deleted the desktop, not Perl ;-)

I've deleted lots of photographs, videos, and whole directories of files accidentally. Some of them were lost forever, some of them were recovered from backup copies. When touching anything of importance, I always switch the mode "production environment" on.

Yes, I know... it was I. And I’ve learned my lesson. Sigh.

I deleted about 6,000 personal photos—at a time in my life when I was trying to be a more serious photographer—once in a similar move a little more than 15 years ago. I didn’t cry or break down. I amortized it over the rest of my life so I’m just a little bit sadder every day than I otherwise would have been. :P It was just “power use” of Unix that time. Perl was not in on the conspiracy for me to be stupid. I got a LOT more serious about never using a root account and ensuring regular old permissions for myself and doing things like–

moo@cow[552]~>alias | ack 'cp|mv|rm'
cp    cp -i
mv    mv -i
rm    rm -i
[download]

Oh! Say, I did actually hose several thousand Amazon.com customers with Perl. Haven’t thought about that in many years. The clue rests in the single most scrub hacker mistake I ever made: s/>>/>/;

The good news there is I spent approximately 30 hours with nearly no sleep after that learning to query the Oracle DB directly to forensically recover from context a good amount of what was lost.

Keeping a single copy of anything, with no backups, is only one step away from it being deleted and lost forever. Automations are supposed to do a lot of work with minimal effort. Working on a filesystem automation in proximity to files you care about and have no backups for is high risk behavior regardless of what language you used. Unless Perl itself malfunctioned, it did nothing it wasn't asked to do.

There are design choices in many languages that are pessimal for safety though; SQL has unguarded DELETE that can wipe out a table just by omitting a WHILE. Perl has > for clobber mode, and < for input mode, a syntactic throwback to shell scripting that has probably made it way too easy for people to mistakenly clobber files.

You mean you deleted the files on your desktop. Your title reminds me of My computer broked down after perl install. Also, passwords.txt, plain text? No backups? What year is this?. Why you left anything important on your desktop is beyond me, then again, we briefly touched on your unconventional workflow previously.

Update: See PhotoRec, there are Linux distros (bootable from removable media) which have lots of digital forensics and file recovery tools. N.B. for best results stop using the computer impacted immediately, to maximise recovery efforts, stop writing to disk...

I did something similar. I had some code with special characters in it (accented chars, mostly) which would lead to problems with some of our tools. I got bored with it and used a perl script to remove every non ascii char from the code. No problem there.

A colleague had the same issue on a different branch, so I told him I would do the same operation again. Except this time I called the script on the root directory of my drive rather than the code folder. Turns out there are a lot of non ascii characters in zipped files, executable files, and other non plain text files :P (It was inconvenient, but all important files were local copies of files backed up somewhere though, so I didn't lose anything)

I have never really had much use for a "desktop" and this is one of the reasons. I always put each "project" in its own directory, mostly to reduce clutter, but also to limit risk to some extent. Avoiding these kinds of mistakes is one reason that I almost never actually replace files in my scripts, preferring to instead write a new output file under another name or in another directory.

While we are talking about disasters, I once tried to make the boot scripts more efficient by picking out the "restart needed" bit from the return code of fsck instead of always needing a restart after checking the root filesystem. Guess what? The shell did not really support extracting a bit from the return code and, the next time fsck changed the root filesystem, startup continued instead of stopping for a restart. Fortunately, I killed the power very quickly, but a few files were destroyed. I had to rewrite /etc/fstab from memory, which led to more fun when I forgot the swap partition. Got all the way into X and managed to start gcc before actually running out of memory. Impressive for a machine with only 64MiB RAM.

See also: PM Confessional.

srsly?

How do I compose an effective node title?