Both of those are vastly safer, because they do not require root privileges, and guarantee to uninstall cleanly.
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)
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.
Save to file, and read the file in the editor.
That said, I generally pipe to file and cat the file, yes, if only because it somehow feels wrong to download it twice.