The alternative is not “install wizard”, it is either “here is a deb file with no post* scripts” or “here is a tar.gz, extract it anywhere and add symlink”

Both of those are vastly safer, because they do not require root privileges, and guarantee to uninstall cleanly.

This. Simply the decision to eschew standard package management already says unpleasant things about their approach to integrating with my environment, or in whatever it is the installation does being reversible using standard tools. "Install wizards" do indeed have exactly the same issue, which is why those are also terrible.

Often these "pipe to Sh scripts" support --help and a variety of configuration options anyway. The benefit of a script over a binary installer at least is that you can inspect the script before running it!

Have you inspected one of these scripts? What have you found? (I've tried it a few times and haven't felt like I learned anything meaningful from doing so.)

I almost always inspect these kinds of scripts before running, more out of curiosity than anything, but also so that I know its not going to do that so stupid that even I can see it's stupid. Usually you can just pipe to `cat`, which is super low effort to do.

I've occasionally seen scripts that install some other application where it was not clear that it was a dependency and there was no heads up to the user that this was going to happen: that kind of behavior makes me more distrustful of the author, so there's a useful signal there.

Most scripts like this seem to amount to "configuration defaults + cli completions installation". To that end, I find looking at them useful because it gives me a sense of the expectations of the tooling and hints at where I might find things if I need to go debugging later.

When they are provided by the same entity as the program you wish to run, I don't see how it's significantly more risky to run these scripts than running the application code itself with the active user's permissions. Still, if there was something, by glancing at the script, you have half a chance of seeing it. If there's something there that doesn't make sense, that's both a "proceed with caution" and a learning opportunity.

cat to terminal is kinda not enough. I can own you very easily if you do just that and think you've seen all the code that will be executed.

Save to file, and read the file in the editor.

It’s not really intended as a defense against being owned per se, it’s more about knowing what’s going on and getting an additional signal about the risk profile (not just from maliciousness) of the thing I’m about to run.

That said, I generally pipe to file and cat the file, yes, if only because it somehow feels wrong to download it twice.

I understand, but cating the saved file or printing from pipe to the terminal directly has identical issues. Terminal ANSI escape sequences are interpreted either way.

Great point. Thank you.

I did!

The usual annoying thing is the automated package install. I have not looked at this particular package, but in the past, I have seen:

- installing specific gcc version and making it system-default.

- installing “virtualbox” packages - this was the worst, as the machine had a few KVM VMs running at the same time, and KVM and VirtualBox cannot run at the same time.

In general, I now stay away from every install script, and if I cannot, then I run it in docker container. Life is short, I do not want to spend it fixing my primary workstation.

(And I examine postinst scripts in deb files too, but those are usually much more boring)

Yuck, those are some really badly-behaved installers.

Yes, plenty of times. Usually I find that they do what you would expect them to do: set up a bunch of parameters like an installation prefix, and then copy files around. They also handle user input options and maybe prompt for some stuff.