• (nodebb)

    Jan didn't send us the uninstall script, and honestly, I assume there isn't one. But if there is one, you know it probably tries to do rm -rf /${SOME_VAR_THAT_MIGHT_BE_EMPTY} somewhere in there. Which, in consideration, is probably the safest way to uninstall this software anyway.

    Take off and nuke it from orbit... It's the only way to be sure.

  • dpm (unregistered)

    Jan S downloaded a shell script and ran it as root, without reading it.

    Wait, what?

    Now, let's be fair, that's honestly a pretty mild WTF; we've all done something similar

    We most certainly have not. Was that sarcasm? It's too early on a Monday morning for subtle sarcasm; come back later.

  • eyalnesher (unregistered)

    If this is just the install script, think how horrible the actual product might be.

  • SG (unregistered)

    I think it's pretty safe to file this one under "malware". Sure, I know the maxim, never attribute to malice what can be adequately explained as stupidity but this is really pushing the bounds of what I can accept as mere incompetence.

  • (nodebb)

    Pretty sure the uninstall script is 

     sudo rm -rf /

  • (nodebb)

    Also "make me a sandwich"

  • yum remove libssl -y (unregistered)

    Install scripts being bad is not that uncommon, I think. The skills you need to construct an actual application are quite different to those needed to script an installer, and yet - because there isn't that much installer work - the people with normal development skills are asked to do the installer too. And because they don't have the skills for that, WTFs abound.

    I'm pretty sure we do 'yum install (dependency) -y' in our scripts in places too, is that not a common pattern? Otherwise the user has to babysit the install to press enter each time.

  • Yazeran (unregistered) in reply to yum remove libssl -y

    I'm pretty sure we do 'yum install (dependency) -y' in our scripts in places too, is that not a common pattern? Otherwise the user has to babysit the install to press enter each time.

    Yep, forcing the admin intalling a program to press y 27 times during an installation because the one component you have to install with yum requires 27 other components which was not part of the default install for that particular version of Linux only results in frustration.

  • Foo AKA Fooo (unregistered) in reply to Yazeran

    At least apt-get (but AFAIK also yum) allows several package names on the command line, so the admin has to press enter just once -- while seeing all the packages you want to install. (This avoids some frustration when they did install 26 packages, to find out the last one is something they absolutely won't install for some reason, and have to abort everything.)

  • Naomi (unregistered)

    forcing the admin intalling a program to press y 27 times during an installation

    Isn't this exactly what yes(1) is for? That aside, it's not hard to provide a --force switch.

  • Foo AKA Fooo (unregistered)

    Some more WTFs:

    • Calling sudo for every single command, rather that running a block of statements (or, more honestly, the whole script) as root anyway. Typically, sudo is configured to cache the credentials for a few minutes, but if not, this will ask for your password lots of times and/or produces lots of warnings in your log.

    • Assuming fixed distro names in the first place. There are some more distros in existence. Just like dnf vs. yum, they could just check if apt-get is there.

    • Creating symlinks from /usr/bin to $install_dir (which may be a user's home directory, and not even readable by other users). That's not how it's meant to be done. Either put the executables themselves there, or if you're not comfortable with that hierarchy, use /opt.

    That said, the lib thing is a little less bad than assumed (not saying it's ok by any means!) since they only (over)write the fully versioned names (*.so.1.0.0), not the *.so links, so they don't really break another installed version. But to be sure, there's no excuse for not installing them via the package manager.

  • Prime Mover (unregistered) in reply to cellocgw

    ZZZAPPPP!

    You are a sandwich.

  • sh ash bash (unregistered)

    The author of this script is so optimistic... By default, if a shell/bash command fails, the script continues. So even if something goes very very wrong, this script will still present the success message to the user.

    A good practice would have been to add the set -e at the beginning of the script, so if a command fails, then the script to exit... So at least when the end of the script is reached, there is a hope for thins working...

  • Worf (unregistered)

    Did no one miss you're copying the same library to /lib and /lib64? They are not the same - /lib64 holds 64-bit libraries while the 32-bit equivalents live in /lib. (This is because most 64-bit processors have a 32-bit legacy mode and thus will run 32-bit code, but 64-bit and 32-bit code can't mix and match - the OS kernel has a compatibility hook that switches everything properly). It's why it's an even bigger mess on Windows, with System32 holding 64-bit binaries, and WoW64 holding 32-bit binaries (WoW == Windows on Windows, and is how Windows runs 32-bit apps on 64-bit).

    And given it's OpenSSL, this is going to result in a LOT of strange and weird errors in your system depending on whether the tool is 64-bit or 32-bit and which architecture the library is for. At best you'll get errors launching the tool, typically odd things like "Invalid executable" or "mismatched architecture" or other oddball error message. Or "exec() failure".

    Is it really a data recovery tool if the host PC running it will need recovery afterwards?

  • sizer99 (google)

    This seems pretty typically enterprisey to me.

  • Chris (unregistered)

    Who the hell named a package manager "Did Not Finish"?! Fills you with confidence, that does.

  • Olivier (unregistered)

    I have seen some enterprisy software with such bad scripts, install and all.

    Given that the open source version is for the few person knowing how to use a command line interface, it is easier to write a README with the list of dependencies: it would take about 3 lines and offer no option to WTF and would be completely fine with the niche target.

  • (nodebb) in reply to Worf

    It's why it's an even bigger mess on Windows, with System32 holding 64-bit binaries, and WoW64 holding 32-bit binaries (WoW == Windows on Windows, and is how Windows runs 32-bit apps on 64-bit).

    There's actually a lot of sense in that terminology:

    • The 64-bit binaries are in System32 because of the Curse of Backwards Compatibility.

    • WoW64 is "Windows on Windows-64".

  • Hasseman (unregistered) in reply to Steve_The_Cynic

    As the Cynic indicates, it is the solution to minimize impact of all WTF's coused by other peoples installation procedures.

  • FrodoB (unregistered)

    This is a pretty optimistic statement, and while yes, it has theoretically been installed to ${install_dir}, assuming that we've gotten this far, it's really installed to your /usr/bin directory.

    This doesn't seem right. All the files have been copied into ${install_dir} and then a link has been made in /usr/bin pointing to those files. Or am I missing something here?

  • Álvaro González (github)

    Why are vendors so reluctant to just build packages and let established package managers do the job? Packages aren't exactly cutting edge technology.

  • (nodebb)

    Actually, specifically in the case of setting a variable, referencing a variable with spaces unquoted works fine. Isn't legacy software just a bundle of fun?

  • löchleindeluxe (unregistered) in reply to Álvaro González

    They stuff that up, too. $TICKETSYSTEMVENDOR releases packages, but those usually fuxx0r the install, because they introduce new undeclared dependencies in bugfix releases, and the dependencies aren't packaged by either $OSVENDOR nor $OSVENDOR's canonical extra repo nor $TICKETSYSTEMVENDOR.

  • (nodebb)

    Just so you know, "yum" on the latest releases is a symlink to "dnf", so it really doesn't matter. Yes there are abominations, and it seems that many people commit then!

  • shebang (unregistered) in reply to Álvaro González

    Because NIH and simpler is always better; rambling, incoherent scripts are always simpler than learning rpm. It's not like we have to support several variants of our huge software products and maintain it all for years to come, right?

  • (nodebb)

    Minor rambling:

    X=blabla${foo}Blabla

    Is actually fine. For some reason, quoting isn't necessary in assignment statements, at least for bash. Still the wrong variable though. And quoting anything BUT the variable substitution is indeed strange.

Leave a comment on “Sudon't”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article