[chrismonsanto]

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]

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.

[kalleboo]

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.

[chrismonsanto]

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

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.