Tag Archives | rvm

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 get.docker.io | 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 https://get.rvm.io | 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 https://raw.github.com/mxcl/homebrew/go)"


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.