Software trends that puzzle me: today, it’s ‘one-line installations’

Maybe my UNIX neckbeard is showing, but the trend of one-line installations confuses me. I guess it’s not fundamentally different than installing whatever random packages you found from some no-name repository, and no admin should be installing things blindly (packaged or otherwise). But it just seems like such an invitation to disaster because if you follow these methods to the letter then you’re executing unread scripts live across the wire. It seems like the sort of thing a developer would whip up for convenience, but I see a ton of admins embracing them now that the trend is loose in the wild.

How about some examples? With pictures!


Here’s an example from Docker, which maybe I’m interested in using for a project at $DAYJOB:

curl | sh -x


OK, so that’s a thing… at least it’s going run that shell in debug mode so you will see what it’s doing.

Ruby Version Manager

Here’s how RVM suggests you install it:

\curl -L | bash


Another instance of “Grab this straight across the wire, and dump it directly into a shell! Do not pass go! Do not bother running this through any sort of sanity check!” I do like that this at least uses the slash in front of curl to make sure you’re not inheriting any aliases when you run it. I guess that that’s considerate of the maintainers?


Over in OS X land, Homebrew also has a one-line installation:

ruby -e "$(curl -fsSL"


I like this one! “Run this curl mess in a subshell, and then feed that into Ruby. Install away!”

What’s the big deal, guy? Just runs them scripts and shuts up.


Inner monologue, you’re a jerk. None of this is a big deal. But these things bug the hell out of me. For starters, I don’t know which irks me more about all of these methods: the use of UNIX-style non-descriptive short flags instead of GNU-style descriptive long flags1, or the fact that there’s no immediately visible validation in these pipelines.

The docs for these tools always say you’re welcome (encouraged!) to download the installation scripts and read them for yourself (which I do — they’re actually very well written and they usually accommodate a lot of the sanity checks and edge cases well) but I know that there’s many, many admins and developers who don’t.

And that’s horrifying.

And it seems like part of a broader trend towards super-dickery2. Along similar lines but without falling victim to the one-line installation trend,RBenv is just sort of dickish (in a short pants, school-boy kind of way) about wanting to know what your shell is doing3.

So what?

YOU GUYS, I can’t run this stuff as-is at $DAYJOB. For any one of these examples I’m going to have to fetch that installation script and save it locally. Then I’m going to have to inspect it and work out what remote resources that script is running. Then I have to figure out how to shove these tools into packages because we version EVERYTHING through packages at $DAYJOB. Science forbid these tools make naive assumptions about their target environment (Hey RVM, storing everything in my home directory is a problem if that home directory is a space-constrained network share; let’s not even talk about I/O if there’s network congestion or disk contention on the remote filer…).

And if there’s any releases/changes/improvements made to these one-line installation scripts between when I ran them in my development environments and when someone (WHO ~~DOESN’T LISTEN~~ IS ILLITERATE) runs them in my production environments then I’ll never see them until/unless I use the one-line method (which then silently introduces the dread environment drift). Put another way, one-line installations make installing the same version of a tool across multiple environments just a little bit trickier.

But I guess that the biggest concern I have is “why did someone think this would be OK?”

  1. GNU-style long flags & options are probably my favorite contribution from the whole of old man Stallman’s GNU project. They’re fantastic when editing/reviewing old shell scripts since they save me/you/everyone we know the hassle of looking up an array of arcane short flags. 
  2. I think of super-dickery as being the act of being an asshole without provocation, based solely on the assumption that the other party is not as smart as you think you are; I am guilty of this more often than not. Also, you know, Superman is a dick. 
  3. I like a good tongue-in-cheek README and I like a strong editorial voice, but this README actually comes across as slightly derisive if you’re trying to take admin-fu seriously. I think that the line “Skip this section unless you must know what every line in your shell profile is doing” is needlessly dismissive, and that’s pants. YMMV, caveat lector, etc. 

, , , , , ,

4 Responses to Software trends that puzzle me: today, it’s ‘one-line installations’

  1. Philip Brocoum June 10, 2013 at 9:45 am #

    It’s important not to confuse problems you have with a particular package with the method of installation itself. These “one-line installations” as you call them have nothing to do with your complaints. Packaged installations, or indeed ANY kind of installations from ANYWHERE, have the same basic risks: you are letting some third-party software modify your system. One line installations are no more or less dangerous than that.

    Furthermore, “security through obscurity” is a well-known mistake. The best way to be secure is to use open and transparent methods, so that you can CHECK that it’s secure, rather than just having “faith” in some proprietary software that SAYS it’s secure. In this manner, these one line installations are the safest and most secure method of installation available: it’s completely 100% open source and transparent.

    Finally, random complaints like the install directory of RVM, or installing a specific version, have nothing to do with one line installations, and everything to do with how the software is made. RVM does in fact allow you to install it systemwide like a “normal” application instead of in your home directory, and it does allow you to specify a “–version” flag when installing it, so both of your complaints are handled. If some piece of software doesn’t allow you to do these things, that’s not the fault of one line installations.

    • Ryan June 10, 2013 at 11:34 pm #

      Hi Phil. Warning: here be verbiage. I’ve had all day to think about this, and I think you raise some interesting points (I also think that you raised a red herring). Let’s talk about them!

      I don’t think the points at hand (“one-line installers are a half-baked developer convenience, and here’s some problems I have with a few of them”) are confused at all; I’ve simply singled out the things that annoy me… at 2:00am. Not necessarily prime critical conversation hours.

      Anyway: RVM, the poster-child for one-line installers that I can stomach.

      I know about the use of optional parameters when installing RVM and you know about the use of optional parameters when installing RVM. But for some strange reason, almost none of the developers that I know (… a statistically insignificant number) who use RVM seem to know about them.

      Yes, anecdotal evidence is garbage. But that’s enough to set my “what the hell, guys?” sense a-tingle. And these guys just keep blowing away their ~/.rvmrc files and fetching head CONSTANTLY. I eventually had to drop /etc/rvmrc files on their systems to get something resembling sanity back.

      It’s important to point out that I’ve singled out RVM as one of the less onerous one-line installations because RVM is a mature product, with many, many, many eyes on it. If anything, it seems to be an exception among a sea of “Imma shove muh codes right here” installers. And even then RVM suffers from having a lot of documentation, but not always having clear documentation — its installer also reinvents a lot of wheels that were already perfectly round and rolling to begin with (a problem that the Ruby community as a whole suffers from, not just RVM). Let’s talk about that, since that’s the biggest problem I have with one-line installers, and it’s not 2:00am so I’m way more coherent.

      As near as I can suss out, the only advantages one-line installations offer over packages are that they:

      1. are vendor platform spec & package manager agnostic
      2. are usually easier to read than the contents of a compressed package

      The first point is kind of nice but it’s also sort of a pain in the ass since it means that I have to make assumptions about the quirks of the installer instead of letting the installer follow the mandates of the platform spec. I admit that I can see that being a feature instead of a bug if you have a heterogenous network of systems and you’re weary of all of the intricacies involved in being a packaging polyglot.

      I don’t think supporting package managers is particularly onerous, so I’m not in that particular camp. Jordan Sissel obviously disagrees with my point of view and we’re probably all better off for how he dealt with the problem. I like his solution a whole lot more than I like one-line installers.

      The value of the second point is inestimable (because clarity trumps cleverness), but package management offers the ability to know the state of a system with much less work on my end. A one-line installation will get the code on my system but it won’t tell me doo-doo-squat about it once it’s in situ. “Just ask rpm” or “just ask apt” is much, much easier than

      first, parse the value of --version for this tool and scrape out its preamble, then parse the value of -version for that tool but split the string because the license string is inline. Now, parse -v for the last tool! It’ll be easy because it’s just a string of numbers!


      I think that robust package management also eases reproducing a system or state (seriously, aptitude-create-state-bundle is fantastic), and the audit trail that package managers produce is just so unbelievably super handy. Here’s some things that rpm or dpkg do really well:

      1. what package does this file belong to?
      2. what files did this package install?
      3. checksum all of the files a package created and report drift

      That is so much work that I’d rather not reimplement a half-dozen times over. I understand that the corollary with one-line installers is that they tend to (but don’t always) create self-contained directories, and when that directory is deleted so is everything they installed. But again, I’d rather the burden of tracking these things be placed on the tools instead of the user.

      Now, let’s talk about that red herring. I think that your point about one-line installers being the most secure installation method is misleading, and I think you might have mistaken my preference for package managers for a preference towards proprietary commercial software. A few points:

      1. I have no problem with commercial or proprietary software, and that’s a whole different discussion.

      2. Being open source is no guarantee of security. Time has definitely proven that more eyes != more secure; if anything it’s proven that we’re not auditing our codebases nearly often enough (especially that Debian bug, which affected Ubuntu, and by extension all Ubuntu derivatives in 2008). I concede that there’s a correlation, but I don’t think it’s 1:1.

      I’m not sure where you got the idea that I’m a cheerleader for security through obscurity (spoiler alert: I am totally not), but I ask you this: realistically, what percentage of users, administrators or otherwise, do you think are actually reading those one-line installer scripts? Probably roughly the same percentage that read the pre & post install scripts in an RPM or DPKG. That kind of behavior is less-than-optimal and it’s not security-through-anything; it’s exec-and-pray and it’s the most common security pattern in IT. It’s also known as someone-elses-problem in some shops, but that’s also an entirely different conversation waiting to happen.

      Finally, while they’re ultimately little more than security theater if you’re not diligent, rigorous, a hardcore security expert, or a cryptographer, the fact that all reputable and well constructed packages are public-key signed is also a level of reassurance that few, if any, one-line installations have. While many of them can be/have been extended to support signed archives I have to wonder how their work integrating these features stacks up against the deeper integration offered by mature package management systems. I also wonder how the relatively shallow number of security-conscious eyes on the one-line installations compared to those that have worked on package management systems stacks up when compared objectively. I don’t have any answers there but it’s probably yet another conversation worth having, by someone, somewhere. Not me though.

      Shit. This reply is longer than the original post.

      • Ryan June 11, 2013 at 12:49 am #

        I should seriously just turn this last comment into another post entirely. Wow.

      • Philip Brocoum June 11, 2013 at 8:44 am #

        One great thing about the open source world is that if you want something done, you can do it yourself. This guy has apparently created a “a sane system-wide rvm installation for debian/ubuntu” here:

        You want an official RVM Debian package? Okay, I volunteer you to be the maintainer 😉

        Like a lot of things, I think it just comes down to taste. Personally, I love one line installers, I love their simplicity, I love that they are cross-platform, I love that they install into a single directory rather than scattering files all over the place, and I love that they just work™. I’ve had far less problems with them than I ever had with package systems.

        I personally can’t stand Aptitude or even Bundler, both of which have been hailed as the second coming of package managers. They’ve caused me nothing but headaches, and I’ve never seen a one line installer fail.

        So HA, I’m countering your anecdotal evidence and statistically insignificant sample with my own!

        I want to end on a philosophical note. First, I’m not sure that “package managers” are theoretically possible in the first place. It might be that package management is just an inherently difficult problem, no matter what. There might not be that magical mystical PERFECT package manager, as much as I’d like to wish there was :-(

        Second, I view open source install scripts the same way I view science. I will never personally perform most physics experiments, but I’m reasonably sure that some scientists somewhere in the world have checked them and reproduced the results. Likewise, I might not read install scrips myself, but even if only 10 people in the entire world read over them, those are probably 10 of the smartest programmers around (because who else would waste time reading such things, except the neckbeards, ha ha? Neckbeards, we love you).

        So yes, I think open source is generally more secure than proprietary. Linux is at least more secure than Windows. So we have one data point.