Comment by amalcon | Hacker News Reader

Comment by amalcon | Hacker News Reader

Piping curl into a scripting environment is problematic for a lot of reasons. For starters, it has a worse user experience than "Download and run this program". I know we love inventing worse user experiences than what's been done for decades, but it's a trend that needs to reverse.

It's easier to mess up security (the early reset thing). This type of install script can't be run offline, because it needs to fetch dependencies (so you can't download it once and run it on multiple systems, and you can never run it on an airgapped system). It accustoms users to pasting commands into shells without knowing what they do, which is irresponsible even without JS clipboard shenanigans.

The author of this page went a lot overboard with the rhetoric, but the simple truth is that there's no good reason to suggest an install method like this. Even taking the exact same script, and asking the user to download and run it is a better plan, because it gives an improved user experience (though still nowhere near ideal).

And yes, I've seen Sandstorm's defense of this practice. I use and very much respect that project, but I couldn't disagree more with the choice of installation method.

> there's no good reason to suggest an install method like this

It is useful for bootstrapping a package manager. Haskell's Stack uses this, Rust uses this, Nix uses this, etc

Why, though? Why is it better than asking users to download and run the exact same script?

Because it's easier for their use case to copy and paste (1 step) than do however many steps you want them to do. If you want to run something offline or run it on multiple machines there is generally a different method available for you to do so. That's not the use case curl | sh is trying to solve in this instance.

Copy and paste is 3 steps:

  - Select text
  - Start up a shell
  - Paste the text into the shell

Download and run is 3 steps for a shell script:

  - Click download link
  - Start up a shell so you can access stdin/stdout/stderr
  - Run the script in the shell

For a GUI program, it's 2 steps:

  - Click download link
  - Run the file from your download manager once it's downloaded

Why is piping the file directly into my shell easier than any of these? It's considerably worse than the GUI option, and slightly worse than the shell option because running programs is something I do from shell all the time.

> Download and run

I generally have a shell open, so it is easier for me to copy/paste into that session than open a file dialog, save a temporary file, (potentially) switch to a different directory, run the script, and delete it.

> GUI program

Creates a temporary file on my disk, needs a correct file association for .sh since the download manager won't save it with +x (for my machine it automatically opens in Emacs, which isn't what I want), I don't even know how to make Linux open a terminal automatically for .sh. I know on Windows cmd.exe would close the window immediately after running the script so you can't see the output. All in all more complicated than just copy and pasting into an active shell session.

The shell is an invariant for script-based installers (i.e. required no matter what). My workflow is also apparently somewhat different from yours, because I tend to open a new shell for each distinct task.

Still, if you're the type of person who generally has a shell open, you can probably figure out how to pipe something from a URL into an interpreter on your own. Which is the better thing to teach to users that can't figure that out?

I haven't manually deleted a temporary file in years, I just have a cron job that clears out my downloads directory. Though this may be a case where my weird workflow changes things from typical, from what I've seen most people just ignore the temporary files.

Most of your objections to the GUI program workflow don't actually apply to GUI programs. I admit that I forgot about the executable bit. I use a mix of Linux and Windows, and basically zero Linux packages have GUI installers -- most prefer .deb/.rpm files, which would be ideal. So I haven't actually run into that before.

It seems like it's only a couple of clicks to fix the permissions in the Nautilus GUI through Firefox, though. Really I would just run the installer from a shell anyway, but that's part of the better user experience: I get to choose that, it's not forced on me.

90% of the command line software I'm installing isn't on my local machine but on either a virtual machine or a remote server. In those cases, "download and run" means

    1. Copy the link
    2. Type wget, quotation marks, paste the link into the shell
    3. Run it
    4. Delete the installer script

Instead of the curl|sh method of

    1. Copy the command
    2. Paste into the shell

If you're installing GUI software then obviously it should have a GUI installer (or the macOS method of just unzipping and drag and dropping the software into the Applications folder), but I've never seen any GUI software installed this way - only command line stuff targeted at developers or system admins who are already going to have a shell open.

Of course, I'd prefer all my software come from the package manager - a separate installer should just be for software that's not quite ready for packaging yet.

> This type of install script can't be run offline, because it needs to fetch dependencies (so you can't download it once and run it on multiple systems, and you can never run it on an airgapped system)

Well, you could if the script was written well enough. Back in the usenet days shar archives were a thing. Basically a shell script that had a large uuencoded payload (which itself was probably a tar file), so that you could just run it and get binaries out.

Of course no one actually does that any more since conversion to unicode bloats the archive considerably. But there's no technical reason why it couldn't.

Reply on news.ycombinator.com