Skip to Content

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

This post should be treated as an historical artifact. It probably contain broken external links and it may no longer reflect my views or opinions.

Maybe my UNIX neck­beard is showing, but the trend of one-line instal­la­tions confuses me. I guess it’s not funda­men­tally different than installing whatever random packages you found from some no-name repos­itory, and no admin should be installing things blindly (packaged or otherwise). But it just seems like such an invi­tation 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 conve­nience, 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 inter­ested 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 inher­iting any aliases when you run it. I guess that that’s consid­erate 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 mono­logue, 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 imme­di­ately visible vali­dation in these pipelines.

The docs for these tools always say you’re welcome (encouraged!) to download the instal­lation scripts and read them for yourself (which I do – they’re actually very well written and they usually accom­modate a lot of the sanity checks and edge cases well) but I know that there’s many, many admins and devel­opers 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 instal­lation 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 instal­lation 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 naïve assump­tions about their target envi­ronment (Hey RVM, storing every­thing 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 instal­lation scripts between when I ran them in my devel­opment envi­ron­ments and when someone (WHO DOESN’T LISTEN IS ILLITERATE) runs them in my production envi­ron­ments then I’ll never see them until/unless I use the one-line method (which then silently intro­duces the dread envi­ronment drift). Put another way, one-line instal­la­tions make installing the same version of a tool across multiple envi­ron­ments 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 contri­bution 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 provo­cation, 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 seri­ously. I think that the line “Skip this section unless you must know what every line in your shell profile is doing” is need­lessly dismissive, and that’s pants. YMMV, caveat lector, etc. ↩︎