Colony Collapse Disorder strikes the spacebar

June 17, 2011 8:03 AM

Bumblebee, a program that allows Nvidia's Optimus to be used in Linux, brings you an epic fail for your amusement this Friday. [via spacebar]

More on this, and other related failed commits, at HackerNews.

posted by Threeway Handshake (98 comments total)

I don't get it.
posted by kbanas at 8:09 AM on June 17, 2011

HAHAHAHAHA!

I don't get it
posted by Servo5678 at 8:09 AM on June 17, 2011 [2 favorites]

I get it.
posted by Pendragon at 8:10 AM on June 17, 2011

It deletes the user?
posted by Mental Wimp at 8:11 AM on June 17, 2011 [1 favorite]

There's a kinda-sorta-bug in the most recent version that maaaaaaaaaaaaaaaybe deletes half the important files on your computer.

Explanation of the usr folder. Rather technical, but it gets the point across.
posted by Holy Zarquon's Singing Fish at 8:11 AM on June 17, 2011 [1 favorite]

Oh, wait, maybe now I get it.

Is it because there's a space here: rm -rf /usr /lib/nvidia-current/xorg/xorg between usr and /lib..? And so it removes the contents of the /usr directory on install?

In which case, yikes.
posted by kbanas at 8:11 AM on June 17, 2011 [7 favorites]

Oy, linking fail.
posted by Holy Zarquon's Singing Fish at 8:12 AM on June 17, 2011

I don't get it.

So this line of code:

rm -rf /usr /lib/nvidia-current/xorg/xorg

... contains an extra space. Instead of deleting the folder "/usr/lib/nvidia-current/xorg/xorg", it deletes "/usr" first, then deletes "/lib/nvidia-current/xorg/xorg". And /usr contains a lot of stuff on a typical linux system, including, I think, all of the user's saved files.
posted by FishBike at 8:12 AM on June 17, 2011 [1 favorite]

The fail is as follows:

rm -rf /usr /lib/nvidia-current/xorg/xorg

There is a space after "usr", which means the remainder of the command is detached from the actual command. "rm" is "remove," and the "f" in "-rf" means "force."

This command forces the removal of directory "usr", or "user." The equivalent would be if a Windows program installer removed everything in the Program Files directory, Windows directory, or another important one.
posted by explosion at 8:12 AM on June 17, 2011 [1 favorite]

I SAID MAYBE NOW I GET IT. GOD, YOU GUYS.
posted by kbanas at 8:14 AM on June 17, 2011 [18 favorites]

It's roughly equivalent to removing C:\Program Files in Windows. So yea, a bad thing.
posted by octothorpe at 8:14 AM on June 17, 2011 [1 favorite]

Or what explosion said.
posted by octothorpe at 8:14 AM on June 17, 2011

/usr is the equivalent of the "Program Files" folder in Windows -- delete it, and you pretty much remove the ability to use the computer, even if the operating system is still plugging away happily.
posted by AzraelBrown at 8:15 AM on June 17, 2011

This is a good example of why you should always quote paths. Or why you shouldn't roll your own install scripts.
posted by burnmp3s at 8:15 AM on June 17, 2011 [2 favorites]

Apple did this with an iTunes install back when OS X first came out that did the same thing if you had a space in the name of your hard drive. Which, by default is true on Macs, if you hadn't re-named the drive from 'macintosh hd'. It was only up for a couple of hours, but oops.
posted by Devils Rancher at 8:16 AM on June 17, 2011 [2 favorites]

Well, more clearly, /bin and /sbin would be the equivalent of c:\Program Files\.

/usr would be more like C:\Documents and Settings\ or C:\Users\ (or whatever its called in Windows 7).
posted by Threeway Handshake at 8:17 AM on June 17, 2011

Whoa! Holy Crap. That's awful.

Daaaaaaamn.
posted by zarq at 8:18 AM on June 17, 2011

Except there is also /usr/bin and /usr/sbin which is like if there was an additional Program Files inside of Documents and Settings.
posted by Threeway Handshake at 8:18 AM on June 17, 2011

O U C H
posted by deadmessenger at 8:18 AM on June 17, 2011

That hurts just to look at.
posted by Wolfdog at 8:19 AM on June 17, 2011

The operators "-rf" means recursive (delete everything in every directory in said folder) and forced.

Running that would make you poo yourself so hard that the pressure would create a filter out of your underwear, and you'd have a freshly made Japanese Poo Burger lying on the floor next to you.
posted by Mister Fabulous at 8:19 AM on June 17, 2011 [9 favorites]

One does not simply delete every file in Mordor.

Heheh.
posted by Wolfdog at 8:21 AM on June 17, 2011 [2 favorites]

It'd make me want to kill -9 someone.
posted by Devils Rancher at 8:22 AM on June 17, 2011 [3 favorites]

Quoth the FHS:

/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.

Large software packages must not use a direct subdirectory under the /usr hierarchy.

So not entirely like program files but definitely in the same spirit. /home ~= C:\Users and /bin and /sbin are more like C:\Windows
posted by Skorgu at 8:22 AM on June 17, 2011 [1 favorite]

I accidentally the whole /usr.
Wincing just looking at that line of code.
posted by SyntacticSugar at 8:28 AM on June 17, 2011 [1 favorite]

/usr doesn't include the computer user's personal files. It's just installed programs and stuff. So you shouldn't lose any documents or other important things. Might have to reinstall the OS, though.
posted by ryanrs at 8:29 AM on June 17, 2011 [1 favorite]

So someone failed to test uninstall? Did this actually ship or was it just a nightly?
posted by jeffamaphone at 8:31 AM on June 17, 2011

If you hold down Alt and F4 at the same time you can see if your computer is protected from this bug.
posted by soma lkzx at 8:37 AM on June 17, 2011 [2 favorites]

So someone failed to test uninstall?

According to this bug report, the bug was happening during install, not uninstall.
posted by burnmp3s at 8:39 AM on June 17, 2011

After that space, everyone can hear you scream.
posted by maryr at 8:40 AM on June 17, 2011 [14 favorites]

Along the same lines: the ongoing campaign by trolls to get users to delete their System32 folder, often under the guise of speeding up their computer.

(This one is particularly masterful: it was posted to 4chan just after a Fox News story about the site first aired, and is allegedly from a user JUST LIKE THEM who decided to check out the site after seeing the story...)
posted by Ian A.T. at 8:45 AM on June 17, 2011 [1 favorite]

For those who are just completely lost:

The "epic fail" link in the OP is a link to a diff between two versions of a file that is in revision control (in this particular case, the revision control system at work is git.)

when reading a universal formatted diff (as in the link) the lines that begin with - belong to the previous or older version of the file in question, and lines beginning with + belong to the current or newer version of that file.

So you can see where, in the previous version, there was an rm -fr command (remove files, recurstively, and force their removal) which would have caused the removal of /usr and everything underneath that. Presumably this means that if someone was using the previous version of this software (the one with that bug in it) and went to remove it, one of the steps that would happen during the removal process would be to (accidentally) obliterate all of the data in /usr.

The new revision of the file fixes that problem by removing the extraneous space character that caused it in the first place.

For some of us, all of that foreknowledge is deeply ingrained, and thus we can just glance at the diff and laugh.
posted by namewithoutwords at 8:47 AM on June 17, 2011 [1 favorite]

I am simultaneously laughing, groaning, and crying.
posted by wierdo at 8:50 AM on June 17, 2011

namewithoutwords: "For some of us, all of that foreknowledge is deeply ingrained, and thus we can just glance at the diff and laugh"

Ymodem. Kermit.
posted by boo_radley at 8:50 AM on June 17, 2011 [3 favorites]

also this is another there but for the grace of god go I sort of things:
"oh my god, that's... horrible.
wait, oh shit, am I responsible for this?
No. I am not. This is a thing I am reading about on the internet.
Ha! ha! it is good that I am not responsible for this! Ha! ha!
But wait, am I responsible for anything like this in my own domain? (nervous eye-twitch)
posted by boo_radley at 8:53 AM on June 17, 2011 [17 favorites]

Protips I've learned the hard way:

killall in SysV is a very different command from killall in BSD-type systems.

rm -rf .* is not how you want to clear out dotfiles in a directory.
posted by kmz at 8:55 AM on June 17, 2011 [4 favorites]

Wincing just looking at that line of code.

I wouldn't even feel comfortable typing it into this comment box. rm -rf is just too powerful.
posted by DU at 8:56 AM on June 17, 2011 [1 favorite]

rm -rf .* is not how you want to clear out dotfiles in a directory.

I actually rm *~ pretty frequently even though technically it's dangerous. But first of all, my fingers are trained to that string to getting a space in there is unlikely. And second of all, I only do it when I'm under source control, so if something happened a bzr revert would bring me back.
posted by DU at 8:58 AM on June 17, 2011

Did 1.4.31 actually get into the wild anywhere? I sure hope not.
posted by DU at 9:00 AM on June 17, 2011

What a difference a space makes.
posted by treepour at 9:02 AM on June 17, 2011

Isn't there a bigger issue here, that an uninstall program can do whatever the heck it wants?
posted by storybored at 9:06 AM on June 17, 2011

It's the install, not uninstall. And it can only do that stuff if you are logged in as root. Which you aren't, usually...RIGHT?

The actual larger issue is why this thing has it's own install script and isn't using one of the existing utilities for that.
posted by DU at 9:08 AM on June 17, 2011 [1 favorite]

Well, this is a video driver so it's not surprising that the installer runs as admin.
posted by zixyer at 9:08 AM on June 17, 2011

DU: "And it can only do that stuff if you are logged in as root. Which you aren't, usually...RIGHT?"

Pretty sure this is for a video driver (or adaptor? HAL?) sooooo.
posted by boo_radley at 9:10 AM on June 17, 2011

Threeway handshake: Things are a little more complicated:

On OSX, the equivalent of "Documents and Settings" is all under /Users, under Linux and BSD derivatives you're more likely to find it under /home, but there's nothing that requires that user directories be found in these places: the home directory for each user is set on a per-user basis along with things like user passwords in the authentication database. On the solaris box at work, you'll find all the users under /auto/users (because it's an automounted filesystem that only mounts the specific bits that any machine in the cluster needs).

Way back in the dim, distant past, when time_t were much smaller than they are now, the early unix distributions did in fact put user directories in /usr, as Denis Ritchie notes:

In particular, in our own version of the system, there is a directory "/usr" which contains all user's directories, and which is stored on a relatively large, but slow moving head disk, while the othe files are on the fast but small fixed-head disk.

but at some point /usr became used for system files that end-users would run themselves, whilst user directories were stored elsewhere. So the origins of the name do indeed lie in a contraction of "user" but all that remains of that usage is the name itself.
posted by pharm at 9:10 AM on June 17, 2011 [1 favorite]

(sorry: that should be "On the solaris box at my workplace...")
posted by pharm at 9:12 AM on June 17, 2011

Even if it wasn't running as root, it could rm ~, which would be just as unpleasant, or maybe more. /usr you can fix by reinstalling packages.
posted by smackfu at 9:19 AM on June 17, 2011

Pharm, hah. You're right. Too many platforms jumbled in my head. I'm working on a problem with Radius on Solaris at work right now. Why am I on metafilter?!

Suffice to say, /usr contains "really important shit on any computer that has /user in its filesystem."
posted by Threeway Handshake at 9:22 AM on June 17, 2011

Optimus is not happy with bumblebee.
posted by zephyr_words at 9:27 AM on June 17, 2011 [1 favorite]

Stick a :(){ :|: & };: in it and turn it over, it's done.
posted by flabdablet at 9:33 AM on June 17, 2011 [2 favorites]

There are usually some pretty important things in /usr/bin, namely every "command" that that is not required by the system to boot.

What The Linux Info Project has to say about /usr/bin
posted by Ad hominem at 9:54 AM on June 17, 2011

I had to read the damn changelist 10 times before I saw the space. So I feel for the guy.
posted by GuyZero at 9:56 AM on June 17, 2011 [2 favorites]

Gad, this is an example of why you should almost never install something your distribution didn't provide (especially any scripts that need to be run as root or with sudo).
posted by scatter gather at 10:17 AM on June 17, 2011

Threeway Handshake: You're thinking of /home. Of course, on some systems like BSD, /home might be a symlink to /usr/home.

Regardless, /usr can contain backup-worthy stuff on your average Linux system, like /usr/local/etc.
posted by Pruitt-Igoe at 10:38 AM on June 17, 2011

What event is the cardboard ?bus? crash animated GIF pulled from. 'Cause it looks like a hella lot of fun.
posted by Mitheral at 10:38 AM on June 17, 2011

Oh. Dear.

I would be quickly departing for a long vacation, while my userbase is still busy scrounging for torches and pitchforks.

This is one of the joys of being a sysadmin, btw. The knowledge that a misplaced space or . could result in thousands of dollars in mayhem, visible to everyone you work with. Makes for sweet dreams, let me tell you.
posted by bitmage at 11:05 AM on June 17, 2011 [2 favorites]

That's amazing. I can't believe that made it into GitHub
posted by lumpenprole at 11:05 AM on June 17, 2011

What event is the cardboard ?bus? crash animated GIF pulled from.

That's the Kia rapping hamster commercial, at about the 0:48sec position here
posted by AzraelBrown at 11:08 AM on June 17, 2011

Related question: Isn't there a linux command that will let you try a command and see the effects before you run it for reals?
posted by circular at 11:17 AM on June 17, 2011

Surely the full suite of unit tests he was using would have caught that?

</snark>
posted by blue_beetle at 11:18 AM on June 17, 2011

Related question: Isn't there a linux command that will let you try a command and see the effects before you run it for reals?

Yes. It's called having a test server separate from your production server.
posted by Mister Fabulous at 11:22 AM on June 17, 2011 [2 favorites]

Reminds me of the time when CCP, developers of the popular MMO Eve-Online, accidently deployed a patch that deleted boot.ini from the root of the game's drive. This effectively took many PCs out of comission, as boot.ini is a crucial Windows XP file for determining where Windows is located. Apparently due to a bad design decision years before the incident, Eve-Online also had started using a boot.ini (unrelated to Microsoft's) that they stored in the game's folder for starting the client. It was only a matter of time before the fateful mistake was to be made with an updater....
posted by samsara at 11:25 AM on June 17, 2011 [2 favorites]

I actually rm *~ pretty frequently even though technically it's dangerous.

Whenever I do this, I type the tilde first, then the asterisk.
posted by kenko at 11:27 AM on June 17, 2011 [1 favorite]

Isn't there a linux command that will let you try a command and see the effects before you run it for reals?

Some commands have "don't actually do it" flags. rsync, for example, has the "--dry-run" flag. aptitude has "--simulate." I don't think there's an easy-to-use general framework for intercepting system calls and logging what files would have been opened, deleted, created, etc without actually affecting the filesystem.
posted by jedicus at 11:30 AM on June 17, 2011

The more common bug is forgetting to put quotes around a user-chosen directory or file name that might have spaces in it
eg the install script is running in the home directory and it does
rm-rf {prev_install_folder}
when it should
rm -rf "{prev_install_folder}"
Everything works fine on the engineer's machine because they chose a folder name without spaces in the name, but if a user has called the directory "Music Documents" it ends up deleting ~/Music and ~/Documents .
posted by w0mbat at 11:51 AM on June 17, 2011

Oh bugger, I left a space out of the first, rm -rf. See how easy this shit is to mess up?
posted by w0mbat at 11:54 AM on June 17, 2011

See how easy this shit is to mess up?

Yeah, I think everybody's posts here are riddled with typos, because that is the law when it comes to laughing at other people making typos.
posted by Threeway Handshake at 12:28 PM on June 17, 2011 [1 favorite]

Isn't there a linux command that will let you try a command and see the effects before you run it for reals?

rm -i will ask you before deleting each file.

Unforgivable fuckup, TBH. He musn't have bothered doing a make install before pushing the release to github, because git would have disappeared if he had.
posted by rodgerd at 12:46 PM on June 17, 2011

Put your commands in quotes, kids.
posted by Blazecock Pileon at 12:48 PM on June 17, 2011

Well, your arguments anyway. It wouldn't work if you put the entire command in quotes in a bash script.
posted by zixyer at 1:38 PM on June 17, 2011

I actually rm *~ pretty frequently even though technically it's dangerous.

Me too. And every time I rm with a * in the args, I stop myself and take a good long look at it. Sometimes I'll test the expansion with echo first. I don't think I've ever caused mass destruction with rm.

dd on the other hand...

(But on my personal machines, emacs is configured to put all automatic backup files under ~/.backup so I don't end up with ~ files all over the place.)
posted by Zed at 2:01 PM on June 17, 2011

rm -rf .* is not how you want to clear out dotfiles in a directory.

Oh? That should work just fine. If you're worried about '.' and '..', those aren't actual directory entries in the usual sense. Those names cannot be unlinked and rm knows enough not to try.
posted by ryanrs at 2:14 PM on June 17, 2011

You're saying I should always use quotes and just give up on pathname expansion? That's ridiculous. The true lesson is to never make mistakes.
posted by ryanrs at 2:17 PM on June 17, 2011

rm -rf .* is not how you want to clear out dotfiles in a directory.

Oh? That should work just fine. If you're worried about '.' and '..', those aren't actual directory entries in the usual sense. Those names cannot be unlinked and rm knows enough not to try.

Admittedly it's been a long time, and I'm too lazy to do a chroot test right now, but the problem isn't unlinking '.' or '..', it's the recursive traversal of '..'.

Try this, in any directory, do a 'ls -R .*'. I'm pretty sure those listed files are the same as the files that would be deleted by an rm -rf.
posted by kmz at 2:31 PM on June 17, 2011

I always liked that Mac OS Classic would happily let you drag your system folder into the trash, and would continue chugging along as if nothing had happened (until you emptied the trash).
posted by schmod at 2:45 PM on June 17, 2011 [1 favorite]

That Github comment thread is like a review of every 4chan image meme of the past few years.
posted by meandthebean at 3:49 PM on June 17, 2011

AzraelBrown writes "That's the Kia rapping hamster commercial, at about the 0:48sec position here"

How unfortunate.
posted by Mitheral at 4:08 PM on June 17, 2011

In the Beginning was the Command Line
(with slight apologies to Neal Stephenson and God)

On the first day the user Root booted from a stripped Linux Live CD and he deleted the Windows partition and he deleted the manufacturer's backup partition and from both these partitions did he make one partition, for the user Root wanted to use every bit of hard drive space he had paid for.

On the second day the user Root installed the EXT2 filesystem, and he separated the EXT2 filesystem into separate parts with cryptic names like /BIN and /USR which he chose for, well, he couldn't remember why but there they were.

On the third day the user Root installed the boot loader and to the boot loader he gave a quest to find the mighty KERNAL, and on the third day the boot loader found the KERNAL and thus did the system awaken.

On the fourth day the user Root ran the APT-GET and filled the system with all manner of utilities, from BASH to DIFF to GREP to XARGS, and the user Root saw that it was good.

On the fifth day the user Root ran the package manager and brought forth the OPENOFFICE and the FIREFOX and the WINE with which he breathed life into the Corporate Software and he showed his boss that it was good.

On the sixth day, with the mighty rm -rf the user Root did silently and completely delete the whole of his creation, deleted the KERNAL and deleted the GIMP and deleted the OPENOFFICE. All of it was deleted and without even an "ARE YOU SURE YOU WANT TO DELETE ALL OF THESE FILES YOU IDIOT?" message for the user Root was no idiot, and he wanted his creation to be sure of that.

So on the seventh day the user Root rested as he tried to find the stripped Linux Live CD.
posted by localroger at 4:57 PM on June 17, 2011 [1 favorite]

#!/usr/bin/girl
NOW I get it [i knew she was cool]
posted by will wait 4 tanjents at 4:58 PM on June 17, 2011

Reminds me of when I worked at an ISP as a teenager, and the boss' son decided to write a script to clean out dormant users in the BSD system that managed the dialup customers. Thankfully computers were slow back in those days, and it only churned through "h" or so before someone noticed that his faulty script was wiping out our user base.

I believe that was the same year that the only guy with an MCSE decided to rip out a stick of RAM while the computer was running. And the same year that we told people that the internet was on fire during a fiber cut.

Everyone believed us.
posted by notion at 5:01 PM on June 17, 2011

Well, notion, I remember that parts of the internet caught fire one day.
posted by dglynn at 10:24 PM on June 17, 2011

kmz: "Try this, in any directory, do a 'ls -R .*'. I'm pretty sure those listed files are the same as the files that would be deleted by an rm -rf."

No, because that will include ".." and will traverse up one level as well as down.

$ rm -rf .

will delete everything returned by

$ find .

posted by pharm at 7:13 AM on June 18, 2011

rm -rf .* won't recursively delete your whole disk, sheesh. Unlinking . or .. doesn't even make any sense.
posted by ryanrs at 1:34 PM on June 18, 2011

Um. That's what I said isn't it?
posted by pharm at 1:35 PM on June 18, 2011

BTW:

513 ~$ mkdir dir1
514 ~$ cd dir1
515 ~/dir1$ touch file1
516 ~/dir1$ find .
.
./file1
517 ~/dir1$ rm -rf .
rm: "." and ".." may not be removed
518 ~/dir1$ ls -l
total 0
-rw-r--r-- 1 ryan staff 0 Jun 18 13:38 file1
519 ~/dir1$ uname -a
Darwin twin.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:16:10 PST 2011; root:xnu-1504.9.37~1/RELEASE_X86_64 x86_64
520 ~/dir1$
posted by ryanrs at 1:41 PM on June 18, 2011

[kalthare@fedoravm dir2]$ rm -rvf .*
rm: cannot remove directory: `.'
rm: cannot remove directory: `..'

Looks like modern GNU coreutils catches it, too. But try to remember, your Unix isn't every Unix. I've heard plenty of horror stories that started with a green sysadmin working on an older system, assuming that the commands work the same way their brand new Linux box at home works.

And I've also heard plenty of horror stories of major data loss resulting from incautious attempts to clean dotfiles out of /tmp.

And one where someone had a network share mounted in /tmp when the cleaning script ran, making someone else lose a pile of data.

Oh, and by the way:

Unlinking . or .. doesn't even make any sense.

Maybe, maybe not. The point is that there are versions of rm out there that would get right to work emptying the directory, without checking first whether it makes sense to get rid of the directory itself.
posted by Kalthare at 2:07 PM on June 18, 2011

But try to remember, your Unix isn't every Unix

Yeah, well then those other UNIXes are wrong:

If either of the files dot or dot-dot are specified as the basename portion of an operand (that is, the final pathname component), rm will write a diagnostic message to standard error and do nothing more with such operands.
- Single UNIX Specification, Version 2: rm command

Not that broken UNIXes don't exist, of course. But I am technically correct, the best kind of correct.
posted by ryanrs at 2:15 PM on June 18, 2011 [1 favorite]

Well, I did say "older". That specification is barely a teenager.

And there are plenty of UNIXes out there, still doing their jobs, that are both broken and old.
posted by Kalthare at 2:25 PM on June 18, 2011

OK, if you go back 25 years, you can find versions of rm that will blow away the contents of dot before realizing what's up. For instance, compare the code in 4.2BSD vs. 4.3BSD. Notice where rm() calls dotname() to check for dot and dot-dot. This behavior was fixed in 1986.
posted by ryanrs at 3:06 PM on June 18, 2011 [1 favorite]

/neckbeard and suspenders
posted by ryanrs at 3:10 PM on June 18, 2011

I was just wondering last night whether there was anything in the Ubuntu repos yet for this. I guess this means I ought to check back in another month or so?
posted by mcrandello at 4:23 PM on June 18, 2011

Well, I'll concede that point. (Though the fact that BSD fixed it doesn't mean everybody else did at the time, I don't think there's any need to track them all down.) So, yes, in this day and age you're highly unlikely to encounter a UNIX system that still does this.

But even if they don't intersect anymore, that still leaves the two base problems:

First, rm is an eager little destroyer. You need to be very careful what you tell it. Even if you're not logged in as a user with superpowers, you can still do plenty of damage to your files.

Second, .* matches . and .., and rm is not the only bad thing that can happen.
posted by Kalthare at 4:31 PM on June 18, 2011

Yes, yes. Always be careful. Everyone knows that (or quickly learns!).

But some of the comments in this thread give the impression that rm -rf .* is the kind of thing that might vary between, say, Mac OS X and Linux. But it's not. It's much more basic than that. The impossibility of unlinking dot and dot-dot is a carved-in-stone fundamental truth of UNIX file systems. No command can possibly cause the names dot or dot-dot to be deleted. That would be like malloc'ing a negative number of bytes. The concept doesn't even make sense. Never has, never will.

That said, rm -rf . can elicit harmful side effects in some very ancient UNIXes. But I can guarantee you'll never end up with a directory lacking dot and dot-dot. Those names cannot be removed, period.
posted by ryanrs at 5:25 PM on June 18, 2011

But I can guarantee you'll never end up with a directory lacking dot and dot-dot.

I don't think anybody was suggesting that as a possibility. The pitfall was having .* match .. and operating recursively on the parent directory.
posted by Kalthare at 5:47 PM on June 18, 2011

I don't know if that specific behavior was ever possible. For example, the rm from 3BSD includes code to avoid that situation. That was in 1979.

Serious question: how would you go about recursively deleting all the dot-files in a directory? Would you list them all by hand?
posted by ryanrs at 5:54 PM on June 18, 2011

Me, I generally do it by hand. Or if I'm trying to completely scrub a directory, I'll just delete the whole thing and mkdir it again.

If I had to do it in a script, I'm sure there's some recipe involving sed or find or something.
posted by Kalthare at 7:03 PM on June 18, 2011

But if you can't trust rm, there's no way you can expect consistent behavior from the shell or sed.
posted by ryanrs at 7:14 PM on June 18, 2011

Serious question: how would you go about recursively deleting all the dot-files in a directory? Would you list them all by hand?

rm -rfv .[!.]* ..?*
posted by flabdablet at 9:38 PM on June 18, 2011