• (cs)

    rm -rf / frist

  • Caecus (unregistered)

    Install comment

    rm -fr /

  • ANON (unregistered)

    Sounds like he had a funny day

  • Lol (unregistered)

    I once dit a similar mistake in a shell script : "rm -rf /var/lib/mysql/$database". Too bad $database wasn't always set... But I was young (and fortunately, I had a backup) Still, the best way to learn sanity checks real fast !

  • ahydra (unregistered)

    I've written code with, and been bitten by, that exact same bug before as well :( Wasn't too painful thankfully, but did piss me off because it undid some work I came in for on the previous weekend.

  • linuxwhiz (unregistered)

    if [ ! "$#" -eq 2 ];then echo "Get backup ready";fi rm $1/$2

  • (cs) in reply to linuxwhiz
    linuxwhiz:
    if [ ! "$#" -eq 2 ];then echo "Get backup ready";fi rm $1/$2
    I found a bug. Try running it with 3 arguments.

    linuxwhiz my arse.

  • linuxwhiz (unregistered) in reply to Zacrath
    Zacrath:
    linuxwhiz:
    if [ ! "$#" -eq 2 ];then echo "Get backup ready";fi rm $1/$2
    I found a bug. Try running it with 3 arguments.

    "what the /" as example ?

  • (cs)

    I hear "rm -rf /" is the most popular answer given to "Installation problem" questions.

  • slipstream (unregistered)

    Coming up next: the DRM installer for Windows that does rd /s /q c:\

  • QJo (unregistered)

    Does nobody use DRY any more?

    Find who wrote that code and give them a "could do better" in their performance review. And ever after bring up the fact that they mucked up something as simple as an installer.

    "Well, yes, we could give you some further responsibility, but you did make that egregious mistake in coding up the installer. Fancy not bothering to put a check on the number of parameters being passed in! Sorry, but "I was in a hurry" is not an excuse here -- we know that the hurry you were in was to get onto something more interesting instead ..."

  • faoileag (unregistered)

    What, no unicorns???

  • josefx (unregistered)

    Nice a WTF implementation of rm. GNU rm requires an additional flag to delete the root dir and afaik from a posix point of view rm is not allowed to delete a parent directory of the rm executable.

  • (cs) in reply to faoileag
    faoileag:
    What, no unicorns???
    If you do see unicorns,,, then you are probably high.
  • faoileag (unregistered) in reply to Zacrath
    Zacrath:
    faoileag:
    What, no unicorns???
    If you do see unicorns,,, then you are probably high.
    For the last couple of months or so all Remy Porter articles had a "cornify" link in it. This is the first one that doesn't.
  • ¯\(°_o)/¯ I DUNNO LOL (unregistered)

    That's not even the most fun problem with using a shell script installers on OS X. Because volume names often have a blank in them (like, say, "Macintosh HD"), that means that paths to a mounted volume (other than the boot disk) are very likely to contain blanks. Failure to properly quote your parameters can cause problems not unlike like this one.

  • slipstream (unregistered) in reply to faoileag

    Who cares. Cornify any webpage by pasting this into Chrome Developer Tools console (or equivalent):

    var cf = document.createElement("script"); cf.src = "http://www.cornify.com/js/cornify.js"; document.getElementsByTagName('head')[0].appendChild(cf); setTimeout(function(){cornify_add()},1000);

  • Jim (unregistered)

    So, what installer? What product?

    Failing to report these names is doing no one a favor except the guilty, who do not deserve protection.

  • Feel Da Rat (unregistered) in reply to josefx
    josefx:
    Nice a WTF implementation of rm. GNU rm requires an additional flag to delete the root dir and afaik from a posix point of view rm is not allowed to delete a parent directory of the rm executable.
    TRWTF is GNU.
  • (cs) in reply to faoileag
    faoileag:
    Zacrath:
    faoileag:
    What, no unicorns???
    If you do see unicorns,,, then you are probably high.
    For the last couple of months or so all Remy Porter articles had a "cornify" link in it. This is the first one that doesn't.
    s/months/years/

    and:

    s/couple of/six/

  • foxyshadis (unregistered) in reply to QJo
    QJo:
    Does nobody use DRY any more?

    Find who wrote that code and give them a "could do better" in their performance review. And ever after bring up the fact that they mucked up something as simple as an installer.

    "Well, yes, we could give you some further responsibility, but you did make that egregious mistake in coding up the installer. Fancy not bothering to put a check on the number of parameters being passed in! Sorry, but "I was in a hurry" is not an excuse here -- we know that the hurry you were in was to get onto something more interesting instead ..."

    That's why these are usually the kind of mistakes where you leave and find a new company, hopefully at slightly higher pay.

  • Paul (unregistered)

    $ set -u $ echo $problem sh: 2: problem: parameter not set

    Imho -u should be default, but it would break all kinds of shoddy scripts...

  • faoileag (unregistered) in reply to foxyshadis
    foxyshadis:
    QJo:
    Does nobody use DRY any more?

    Find who wrote that code and give them a "could do better" in their performance review. And ever after bring up the fact that they mucked up something as simple as an installer.

    "Well, yes, we could give you some further responsibility, but you did make that egregious mistake in coding up the installer. Fancy not bothering to put a check on the number of parameters being passed in! Sorry, but "I was in a hurry" is not an excuse here -- we know that the hurry you were in was to get onto something more interesting instead ..."

    That's why these are usually the kind of mistakes where you leave and find a new company, hopefully at slightly higher pay.
    With that kind of behaviour shown by a team lead towards a team member I would try to find a new company regardless of whether it was me making that mistake or not.

    First thing to consider is who the culprit is. Those that fail to check if a contract is honoured or those that do not honour a contract? After all the article clearly states "the binary which was supposed to trigger the shell script had forgotten to pass any parameters".

    Second: What about code reviews? It's the team lead's job to see that these take place (and I seem to recall that QJo is a fierce advocate of those). A second pair of eyes is a very good insurance against such problems.

    And finally, since the behaviour proposed is rather arrogant ("Fancy not bothering to put a check on the number of parameters being passed in!"): Fancy thinking that a check on the numbers of parameters alone is enough.

  • EvilSnack (unregistered) in reply to QJo
    QJo:
    Find who wrote that code and give them a "could do better" in their performance review.
    And QA should be told, "This passed. Explain how you will prevent that in the future."
  • faoileag (unregistered) in reply to Paul
    Paul:
    $ set -u $ echo $problem sh: 2: problem: parameter not set
    Does that work on a Mac with tcsh? From what I gleaned from a quick google search, it doesn't...
  • thome (unregistered) in reply to slipstream

    The WIDComm Bluetooth drivers are notorious (at my workplace at least) in that uninstalling them does pretty much exactly that: it removes everything from the C: drive.

  • peon (unregistered) in reply to EvilSnack
    EvilSnack:
    And QA should be told, "This passed. Explain how you will prevent that in the future."

    That assumes there is QA. This is not always the case; usually QA is last-hired, first-fired, with the assumption that "developers check their own code, so QA is a luxury."

    I wish I was making this up...

  • History Teacher (unregistered) in reply to QJo
    QJo:
    that they mucked up something as simple as an installer."

    While this particular problem is kinda... unforgivable, if it slips into released code, I take exception with "as simple as an installer."

    An installer has about as many failure modes, as there are slightly differently set up machines out there, now and decades into the future.

    Writing a robust installer requires diligent testing and paranoid attitude. Make one wrong assumption, forget to test parameters in one case, and Mr. Murphy will get you (or at least the end user). And it does not help, that management usually thinks installers are simple and should have been completed yesterday. Even if there is an incident, it's not because implementing an installer was not taken seriously enough, it's because of incompetent developer who couldn't write a simple installer.

  • Fritz, a.k.a. Fritzo (unregistered)

    I like Benjamin's a.k.a. Benjamo's "HEY THIS THING DOESN'T WORK SO IT'S OBVIOUSLY BADLY CODED; LET'S JUST GIVE IT MORE PRIVILEGES LOL" approach.

  • (cs)

    When I was still a college student in the very early 90's, on a co-op placement, the company I was working at provided training seminars to its clients. To make sure that each student's experience would be the same, there were standard installation sets for each group of courses.

    My job one day included reinstalling the UNIX operating system and applications on a half-dozen machines from the installation CD for a class starting the next day. As I was starting the whole process, I went to one of the machines, knowing I was going to rebuild the machine anyway, logged in as root and ran rm -rf / in a ksh session to watch what happened, while I rebuilt the other machines. After about 10 minutes, the GUI started failing and the process took over an hour before I got a message at rm could not remove everything. I have no idea what was still in the machine because I could use ls for some reason. So, I gave up in frustration and inserted the installation CD and rebooted the computer. 15 minutes later or so, the results of my experiment were all replaced with a functioning machine.

  • (cs) in reply to josefx
    josefx:
    Nice a WTF implementation of rm. GNU rm requires an additional flag to delete the root dir and afaik from a posix point of view rm is not allowed to delete a parent directory of the rm executable.
    On Unix an open inode can have zero links to it, so I see no reason whatsoever for rm to be somehow special - the on-disk file (link) can vanish, it's fine. Even the working directory can vanish IIRC - again, the directory inode is open, without links. That's what IMHO Windows/NTFS got wrong. All those ugly workarounds for self-deletion of an uninstaller are driving me nuts - with everyone and their mother continuously reinventing the wheel in that department. I've seen way too many "clever" (read: mostly not working) ways of "deleting" open files.
  • Pock Suppet (unregistered) in reply to Feel Da Rat
    Feel Da Rat:
    josefx:
    Nice a WTF implementation of rm. GNU rm requires an additional flag to delete the root dir and afaik from a posix point of view rm is not allowed to delete a parent directory of the rm executable.
    TRWTF is GNU.
    GNU's not Unix - it's TRWTF?
  • faoileag (unregistered) in reply to Fritz, a.k.a. Fritzo
    Fritz:
    I like Benjamin's a.k.a. Benjamo's "HEY THIS THING DOESN'T WORK SO IT'S OBVIOUSLY BADLY CODED; LET'S JUST GIVE IT MORE PRIVILEGES LOL" approach.
    Standard mode of operation in the windows world. Oracle's Java updater can't even check for updates without escalated privileges.

    And also not unheard of in the linux world. Unless you use a packet manager, the standard way to get things done is get the sources and install from them. There the standard goes like "configure; make; make install" and while you can perform the first two steps as a normal user, the last one usually requires root privileges.

  • nobulate (unregistered)

    That's what you get

    For installing a DRM client. Shame on you!

    quis: the sound your body releases when you realize you just rm -rf'd your disk.

  • I forget (unregistered)

    The real WTF is Apple Macintosh using archaic old Unix scripting. Ah the good old days of Classic MacOS when it didn't even have a command interpreter at all.

    Of course even if there were a superior tool for installers, fools would still find a way to accidentally delete the entire hard drive.

  • Ganna (unregistered)

    Reminds me of this: https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac

    laoreet: a lousy sysadmin

  • eggplant (unregistered)

    I always tell people the -rf flag means "really fast".

  • Chad Garrett (unregistered)

    Finally! A DRM solution that works. If you delete EVERYTHING, it makes it hard for the user to make illegal copies.

  • n_slash_a (unregistered) in reply to faoileag
    faoileag:
    Fritz:
    I like Benjamin's a.k.a. Benjamo's "HEY THIS THING DOESN'T WORK SO IT'S OBVIOUSLY BADLY CODED; LET'S JUST GIVE IT MORE PRIVILEGES LOL" approach.
    Standard mode of operation in the windows world. Oracle's Java updater can't even check for updates without escalated privileges.

    And also not unheard of in the linux world. Unless you use a packet manager, the standard way to get things done is get the sources and install from them. There the standard goes like "configure; make; make install" and while you can perform the first two steps as a normal user, the last one usually requires root privileges.

    Agree. Most of the time an install fails due to insufficient privileges. Running the install with elevated privileges is actually pretty SOP.

  • Paul (unregistered) in reply to faoileag

    The script started with #!/bin/sh; I'd expect that'd be the standard sh and support -u. If not somebody at Apple should be very ashamed...

  • (cs) in reply to Fritz, a.k.a. Fritzo
    Fritz:
    I like Benjamin's a.k.a. Benjamo's "HEY THIS THING DOESN'T WORK SO IT'S OBVIOUSLY BADLY CODED; LET'S JUST GIVE IT MORE PRIVILEGES LOL" approach.
    Old school approach... ISVs basically ignored Microsoft's security model and continued assuming the user had full privileges to even RUN programs, not to mention install them, until Vista came out.
  • Tzafrir Cohen (unregistered) in reply to Feel Da Rat
    Feel Da Rat:
    josefx:
    Nice a WTF implementation of rm. GNU rm requires an additional flag to delete the root dir and afaik from a posix point of view rm is not allowed to delete a parent directory of the rm executable.
    TRWTF is GNU.

    The requirement that 'rm -rf /' will do nothing was added to POSIX according to requirements of people from Sun.

  • AnOldHacker (unregistered)

    Okay, let me get this straight: You're on a Mac---and complaining about DRM?

    O.o

  • Tzafrir Cohen (unregistered)

    OS/X often claims being POSIX-compliant (blaiming GNU/Linux distributions of not being). Maybe the author of the script counted on that? Ahem.

    Anyway, note the "#! /" (with the space) in the first (she-bang) line. This was required from the time when the magic (used to identify the executable) was always four bytes.

  • Jim Blog (unregistered) in reply to faoileag
    faoileag:
    And also not unheard of in the linux world. Unless you use a packet manager, the standard way to get things done is get the sources and install from them. There the standard goes like "configure; make; make install" and while you can perform the first two steps as a normal user, the last one usually requires root privileges.

    Although at least most configure scripts at least allow you to specify an alternate installation location - somewhere you can write to without needing root. Software that's only available as RPM is a pain, because without root you literally cannot use it.

  • (cs) in reply to Zacrath
    Zacrath:
    I hear "rm -rf /" is the most popular answer given to "Installation problem" questions.

    Better yet: % sudo rm -rf /

  • Juho AKA Juhoo (unregistered) in reply to Jim Blog
    Jim Blog:
    Software that's only available as RPM is a pain, because without root you literally cannot use it.

    Surely this can't be true? I'm too lazy to check now (busy... ehm compiling) but there must be something like "dpkg-deb -x test.deb testdir" that lets you unpack the rpm wherever you want.

  • QJo (unregistered) in reply to faoileag
    faoileag:
    foxyshadis:
    QJo:
    Does nobody use DRY any more?

    Find who wrote that code and give them a "could do better" in their performance review. And ever after bring up the fact that they mucked up something as simple as an installer.

    "Well, yes, we could give you some further responsibility, but you did make that egregious mistake in coding up the installer. Fancy not bothering to put a check on the number of parameters being passed in! Sorry, but "I was in a hurry" is not an excuse here -- we know that the hurry you were in was to get onto something more interesting instead ..."

    That's why these are usually the kind of mistakes where you leave and find a new company, hopefully at slightly higher pay.
    With that kind of behaviour shown by a team lead towards a team member I would try to find a new company regardless of whether it was me making that mistake or not.

    First thing to consider is who the culprit is. Those that fail to check if a contract is honoured or those that do not honour a contract? After all the article clearly states "the binary which was supposed to trigger the shell script had forgotten to pass any parameters".

    Second: What about code reviews? It's the team lead's job to see that these take place (and I seem to recall that QJo is a fierce advocate of those). A second pair of eyes is a very good insurance against such problems.

    And finally, since the behaviour proposed is rather arrogant ("Fancy not bothering to put a check on the number of parameters being passed in!"): Fancy thinking that a check on the numbers of parameters alone is enough.

    Apologies, you misunderstand. I wasn't claiming that this is what ought to happen, more likely what probably would happen if Murphy ruled, and was in fact something which happened to me once, although it was on a VAX and it wasn't quite so devastatingly bad as rm -rf / (the details of exactly what it was I did do are lost to history).

    This sort of script is the sort of thing which rarely makes it to code review. It rarely makes it out of the IT support team, as installation and configuration are usually in their department, not that of the regular customer-facing development-code team. And QA will not tend to be called in for it either. That, of course, is a complete WTF in itself.

  • Mojo Loco (unregistered) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    That's not even the most fun problem with using a shell script installers on OS X. Because volume names often have a blank in them (like, say, "Macintosh HD"), that means that paths to a mounted volume (other than the boot disk) are very likely to contain blanks. Failure to properly quote your parameters can cause problems not unlike like this one.
    Much like Apple's own iTunes 2.0 installer.

    CAPTCHA: eros. I'm in love with iTunes!

  • Andrew Stein (unregistered) in reply to faoileag

    csh/tcsh always throw an error when accessing unset variables. For all the heat csh/tcsh take, this is a great feature.

    $ tcsh

    echo $problem problem: Undefined variable.

Leave a comment on “The Uninstalling Installer”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article