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

71–80 of 111 posts

Re: The Audacity of Piping Curl to Bash

#71

Post by simiones »

mjw1007 wrote: post #17
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.

Yes, having a proper method for uninstalling is one big advantage of "proper" installers (like .deb packages or .msi installers on Windows) - though of course there is no guarantee even then that it will properly clean-up the system.

However, having a package that simply installs some files and then tells you "copy these lines to your .bashrc and modify this mount file and [...]" to set up your system is really not that much better - if you follow those instructions, it will be up to you to manually un-follow them if you later decide to stop using this package. And while whoever wrote the installer may or may not properly undo what what they installed in the uninstaller, I can guarantee that no one will provide an uninstaller which un-does changes you manually made.

Re: The Audacity of Piping Curl to Bash

#72

Post by dllthomas »

nhooyr wrote: post #69
dllthomas wrote: post #40

Earlier quoted context omitted.

If curl dies early, bash might be executing a truncated script. Arbitrarily truncated bash scripts are often valid bash scripts that do things you don't want.

You can trivially sidestep this with a main shell function called at the end of your script. https://github.com/terrastruct/d2/blob/729b12685af79bbdaf4b3...

Kinda! The author of the script can trivially avoid the problem. The person pasting "curl ... | bash" into their terminal needs to rely on them having done so, which (last I looked) they too often haven't.

Re: The Audacity of Piping Curl to Bash

#73

Post by bravetraveler »

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

With things like the OpenSUSE build system... I see this more as a one time cost

You write the spec files for the managers of choice; DEB, RPM, PKGBUILD, whatever

With that you parameterize the inputs. The version to build, where to get the sources, etc.

Maintaining these is... note your build/runtime requirements the same way you do while developing.

Once the specs are written the laborious work is finished. There are countless tools to make this less effort, eg: pyp2rpm and alien

I maintain packages through Fedora COPR, a similar system. These tools are my first pass at writing the spec for things I don't even own.

I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it.

This is a critical first step to being bundled in the distribution itself. You won't get maintainers if there's nothing to maintain.

Re: The Audacity of Piping Curl to Bash

#74

Post by simiones »

Brian_K_White wrote: post #56

Reading all the comments not understaning the problem is a great way to feel old. It's definitely a new generation, only in the bad way where instead of meaning new energy, imagination, and progrrss, it just means forgot or never learned important concepts and principles. You do not take liberties with someone else's system, there is no need to do it and no excuse for it. You can have a reference example "make instal…

> You do not take liberties with someone else's system, there is no need to do it and no excuse for it.

The whole point of the oh-my-zsh installation script is to modify your system to work with oh-my-zsh. If you don't want your system modified, you shouldn't run it: there is no other point of that script.

Build instructions are a completely separate thing, and are a complete distraction. No one sane waits for some random distro to discover your software and decide to package it themselves as a means of distributing it.

As far as most people are concerned, the role of things like apt or rpm is to manage the base system. Installing and keeping application software up to date is best left to the applications themselves - as it has always been on Windows or MacOS (before the app store craze), as it should be. It is not and should not be up to the Debian maintainers to tell me what version of Firefox to use, or how often I should update it.

Edit:

> Respecting the possibility that a config file or even the bins and libs might already exist as part of the "make install", are just part of the job like writing the software itself, not some unreasonable extra burden.

I assume you are referring to the author's complaint about the installer overriding their ~/.zshrc. If so, then that is again a misunderstanding of the point of this script - it explicitly tells you right in the description that it will do that AND it keeps the old file around in case you still need it.

To explain again - oh-my-zsh is a system for controlling your zsh installation. It's whole purpose is to take over things like your .zhsrc file. This is explained very clearly on their main page, so running that script and expecting it to not modify your zsh settings is like installing Firefox and expecting it not to connect to the Internet when you type a URL in the address bar.

Re: The Audacity of Piping Curl to Bash

#75

Post by [deleted] »

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…

[deleted]

Re: The Audacity of Piping Curl to Bash

#76

Post by mustache_kimono »

bravetraveler wrote: post #73
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.…

With things like the OpenSUSE build system... I see this more as a one time cost You write the spec files for the managers of choice; DEB, RPM, PKGBUILD, whatever With that you parameterize the inputs. The version to build, where to get the sources, etc. Maintaining these is... note your build/runtime requirements the same way you do while developing. Once the specs are written the laborious work is finished. There a…

> I practice what I'm preaching, and I really don't buy that it's a lot of effort. If you want users, do it.

I've heard a lot about these systems, and, if they do what they promise, I think this is great. Exactly what is needed. I already do package and distribute my software. My comments are mostly directed at those who have a problem with those who don't, because that's a fine choice too. It can also be a fine choice for awhile. The problem is mostly one of attitude, we need less user entitlement re: packages. Packages are something I will get to if I want to, when I have the time, and if it interests me.

I would note there are other problems with the package manager ecosystem which make it ill-suited to packaging Rust apps, for instance. I am not an Arch user, but Arch really is leading the way here: https://wiki.archlinux.org/title/Rust_package_guidelines

Re: The Audacity of Piping Curl to Bash

#77

Post by mustache_kimono »

denton-scratch wrote: post #48
mustache_kimono wrote: post #30

Earlier quoted context omitted.

> "we the users" could mandate Yuck. As I said: > Instead, it is always someone else's problem. "I am the customer mentality" has been with FOSS and Linux for awhile, but one wishes people might shake themselves out of their stupor for 2 seconds to realize: "You're getting all this stuff for free." Instead, every user wants to man the battlements on Reddit and tell devs how to do the thing. Re: the parent, she/he sho…

> "You're getting all this stuff for free." Of course. Part of packaging something, and then releasing it through a distro's package manager, is that it goes through the distro's release process; someone reviews it. It becomes part of the distro. In particular, if it goes into something like Debian's "main" repository, I'm inclined to trust it almost as much as I trust the core OS release. I'm not going to man battle…

> I'm not going to man battlements anywhere over this kind of thing

Totally agree. A preference is fine. A demand that devs do something different with their limited time and resources is nonsense. Making the choice not to package and distribute is fine. Then -- it just becomes someone else's problem. You hate omz's update method? Then be prepared to package it yourself. That's all I'm saying.

Re: The Audacity of Piping Curl to Bash

#78

Post by ilyt »

mjw1007 wrote: post #17
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.

It's almost admission of guilt, nobody ever thinks about that uninstall.

Even workse if app starts with sudo to install some stuff in system directories

Re: The Audacity of Piping Curl to Bash

#79

Post by ilyt »

user3939382 wrote: post #51
dagmx wrote: post #50

Earlier quoted context omitted.

Uninstalling macOS apps is usually as simple as removing the app bundle.

If only that were true. Apps leave their config and support files all over the file system.

Right but few kbs of config is less of a bother than few hundred megs of deps installed all over the place.

The config and data is iffy situation because you might want to uninstall just to install new version, and so might want them to stay, might want them gone.

Re: The Audacity of Piping Curl to Bash

#80

Post by geocrasher »

My issue with piping curl to bash is that so many of these installers are pure junk.

Case in point: I work in web hosting. Yesterday a customer came to me asking for root access to the node so they could run an installer for something. No. But they had already tried running it as their user. And everything in their user account was gone. Why?

Because the installer expected to run as root, and its variables couldn't be defined properly and so when it went to clean up after itself, it did

   rm -rf ~/$variable/
and since the variable was unassigned, that became

   rm -rf ~/
I might not have it exactly right, but that's what the effect was. Piping curl to bash is asking a lot of somebody who doesn't know what they're doing, and should raise the hackles of somebody who does. At the very least, download and view the script yourself before running it.
Post reply on HN