Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Audacity of Piping Curl to Bash

yotam.net

Post reply on HN
Print view View original

11–20 of 111 posts

Re: The Audacity of Piping Curl to Bash

#11

Post by mustache_kimono »

Un1corn wrote: post #3
ragingrobot wrote: post #2

Quite a few applications do this. For something like the mentioned oh-my-zsh, it can be safely assumed the user is not a novice in most cases. Having to install in this manner may in fact deter the user, as they'd be suspicious. A well written README would be the better route.

I don't remember all of the times I've encountered it but a couple of examples I remember are rustup with its 700 lines of shell script (although you can install rust normally of course) and pi hole with its whopping 2700 lines of shell script.

> rustup with its 700 lines of shell script

I wouldn't trust a shipping shell script with less than 200 lines just re: sanity checks.

Large shell script programming stinks. The person who wrote it probably swore off shell as soon as they were done. But it is portable and it isn't half the pain that packaging for several distros is.

Re: The Audacity of Piping Curl to Bash

#12

Post by hprotagonist » 

  curl ... | bash
is the moral equivalent of

  {npm, pip, nuget, ...} install
and i really don't understand the folderol around that. In both cases, you can alter the command slightly to instead download the payload without executing it and inspect it first, if you wish. In both cases, you're ultimately going to either audit and then execute or just execute code from Somewhere Else.

This is true for distro package managers too, though you could argue that sometimes but not always (ppas, community/, whatever) a distro package manager is an extra layer of insulation between you and nasty stuff.

Re: The Audacity of Piping Curl to Bash

#13

Post by sjmulder »

Another downside of these scripts is that they tend to make changes to your user or machine configuration, something which is tolerated from Windows installers but a big no-no for me. E.g. I believe Cargo edits .profile to add its path and Teams makes itself start at login (!).

For reasons such as these, but also things like telemetry configuration defaults and clean uninstalling, I prefer using a package manager. In a way independent package maintainers balance out the power of upstream developers over end users. They embody “you can just change it if you don’t like it” for the regular user.

Re: The Audacity of Piping Curl to Bash

#14

Post by simiones »

mustache_kimono wrote: post #6

> If my package manager had an Oh My Zsh package This is the author missing the point. The reason `curl | bash` is common is because devs don't like packaging for every distro under the sun, and MacOS, and FreeBSD, and... If you really think `curl | bash` is the problem, then you should be lining up to package the stuff you use for your distro. Instead, it is always someone else's problem. Package managers are great.…

It's even worse than that. The way common distros work is not "devs package software", it's "devs convince distro to pick up the package and maintain a fork".

Of course, you can run your own APT or RPM repo, but that actually asks your users for even more control of their systems (since you now have a way to get any new version more or less automatically installed on their system in perpetuity), and it makes it even harder for them to install your software.

You can also bundle your software as a .deb + .rpm + .[...] file instead of a .sh file, but there is really not that much difference.

Re: The Audacity of Piping Curl to Bash

#15

Post by mustache_kimono »

superkuh wrote: post #4

Not just applications. Entire programming languages like Rust depend on this to install the compiler (rustup, since rustc changes too fast for anything but the most rolling of distros to keep up).

> Entire programming languages like Rust depend on this to install the compiler

And it works! For people who have to stay on top of language changes (not everyone), who are on a wonky platform or that doesn't update quickly enough, this is actually a pretty okay method. And they do also offer alternative methods: https://rust-lang.github.io/rustup/installation/other.html

Here, the "You know what they should be doing..." attitude surely doesn't account for something.

> rustc changes too fast for anything but the most rolling of distros to keep up

This may have once been true, but isn't really anymore. Ubuntu updates all distros with the latest and greatest and does so about every couple of minor version releases (last was 1.59 to 1.61). This is fine for me. My MSRV is now whatever Ubuntu is shipping.

Re: The Audacity of Piping Curl to Bash

#16

Post by rascul »

superkuh wrote: post #4

Not just applications. Entire programming languages like Rust depend on this to install the compiler (rustup, since rustc changes too fast for anything but the most rolling of distros to keep up).

It's one way out of several to install rust. And interestingly enough, my distro maintains a more up to date rust than I do myself.

Re: The Audacity of Piping Curl to Bash

#17

Post by mjw1007 »

simiones wrote: post #9

This seems almost like a misunderstanding of what is the role of an installer, especially for something like oh my zsh. The author is complaining that it takes over their zsh configuration, when in fact that is obviously the whole point of the installer. An installer isn't simply there to copy a program to your system. It's there to copy files to your system and then modify your system so that it is ready to use the…

The other part of an installer's job is to provide a reliable way to uninstall the program, without leaving any mess behind.

I think that's the main reason I'm reluctant to run curl|bash-ware. I might trust the authors not to be malicious, but I generally wouldn't trust them to be competent at cleaning up after themselves.

Re: The Audacity of Piping Curl to Bash

#18

Post by ArchD »

When I want to be careful about running these setup scripts, especially just for trying out new software, I run them in a docker container to limit whatever damage the scripts can cause. When the script is complicated, I tend to use docker instead of trying to understand the script and then run it on the 'real' system.

Then when I really like the software and want to install it on the 'real' system, if there's much benefit in doing so, I spend more time and effort understanding the script. More often than not, I end up not doing this because there is no compelling need to install the software on the 'real' system.

Re: The Audacity of Piping Curl to Bash

#19

Post by NuSkooler »

Package managers are sometimes great for the user, and as mentioned, a pain for the developer in many cases. To cover even "basic" bases, the developer has to manage many package managers. Ouch.

From the user side, the package manager often doesn't do what I want, either. I could install Node (as an example) via `apt` or `yum`, and end up with a Node installed in a root location. Now I'm in a mess. Or I could use a install script, or even yet another 3rd party solution such as `npm` to do what I actually want: Node installed for me. ...of course, I just mentioned a whole other can of worms: All the "other" package managers out there.

TL;DR: KISS often is the best solution.

Re: The Audacity of Piping Curl to Bash

#20

Post by Sakos »

spsesk117 wrote: post #10
Sakos wrote: post #5

> I would have just expected it to install it in the proper location (hopefully not in my home directory) and leave the rest of the configuration to me While I don't advocate for piping curl to bash, this is exactly what I expect an installer to do. It should provide sane defaults that don't require me to fiddle around with manpages or other documentation and config files before I can even use the thing. I'd say that…

> I think what's missing is some standardization around what an installer is allowed to do I don't mean to be facetious, genuinely curios, but to the authors point, isn't that the point of the package management system? It's a standardized and encapsulated way to provide software, with sane defaults, in an auditable way, that respects the users system. I tend to agree with the author here, but I'm sympathetic to the…

> packaging for rpm/deb (in my experience) can sometimes be an enormous pain with many hoops to jump through, _especially_ if you're trying to get your package accepted upstream

I would say this is the primary pain point for maintainers, which is why we're suddenly seeing bash scripts instead. The technical complexity and the process of upstreaming and then doing this for a bunch of different distros. If they're already rejecting package management systems because of their current state, the solution isn't "well, why don't they just use existing package management systems".

Post reply on HN