4 ms·

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"

by amalcon 10y ago

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.

chrismonsanto 10y ago
> 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
- amalcon 10y ago
  Why, though? Why is it better than asking users to download and run the exact same script?
  - chrismonsanto 10y ago
    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.
    - amalcon 10y ago
      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.
      - deleted 10y ago
        [deleted]
      - chrismonsanto 10y ago
        > 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.
        amalcon 10y ago
        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.
__david__ 10y ago
> 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.

by amalcon 10y ago

chrismonsanto 10y ago

> 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

amalcon 10y ago
Why, though? Why is it better than asking users to download and run the exact same script?
- chrismonsanto 10y ago
  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.
  - amalcon 10y ago
    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.
    - deleted 10y ago
      [deleted]
    - chrismonsanto 10y ago
      > 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.
      - amalcon 10y ago
        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.

__david__ 10y ago

> 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.