Pipe the script to cat before you pipe it to sh and take a look. It's downloading an executable to ~/.local/bin. If that's not your preference, there are many other options for obtaining the software, via your distribution or manually. I feel the backlash to this pattern is pretty overblown. They're not attempting to hide anything, just make the common case convenient.
A lot of the backlash is around the tool downloading and running an arbitrary shell script which could contain anything, and overlooks the fact that that shell script then downloads an opaque binary which could also contain anything. If you're paranoid about security read the code and build it from source, otherwise curl | bash is trusting the authors just as much as any other method.
Probably the biggest problem with the `curl | sh` approach is it bypasses package maintainers. I agree it's really no different than if you compiled malicious code yourself (or pulled in a 3rd party bin repository). However, one of the functions of a package maintainer is finding/being notified of security issues.
I'm thinking of the recent xz attack. Imagine how bad that would have been if xz was commonly installed via `curl | sh`.
All this is to say `curl | sh` is probably fine if the org is reputable, however, you should be having second thoughts if this is a repo ran with a bus factor of 1.
Yet the xz attack specifically targeted the packages and nothing else. And it worked, to a point. All I’m saying package maintainers are human and can’t detect everything.
Sure, but that convenience will come to bite you later. What happens when you want to update it?
Their full install docs is like 5 lines of code so it is much preferred to do it that way. Every distribution is different. The ideal install here would be to add a unique apt repo for zed and then it becomes part of my normal update process. Updating a binary in a directory is not the end of the world... but I would prefer to know that upfront versus needing to hunt down where it was placed in order to do the updates.
edit its 4 lines. seeing this is much preferred to parsing a bash script that is intended to support all distributions:
Suggesting that users install software outside of official repos isn't more convenient than using a repo and standard package management tools. As soon as there's an update, you'll learn exactly why that is the case.
You can just read the script that you're curling rather than pipe it into sh directly. It seems like it just extracts the binary from a tar.gz and puts it into ~/.local.
"reading a script" is actually a worse user experience on Linux than just using repositories or flatpak, though. It's pretty rude of software developers to put the onus on users to verify that they're not doing something outright malicious in terms of the installer.
Most repositories have some sort of vetting process as far as I'm aware. In the case of Zed, because it's open-source, it can be examined more completely, although I don't think it's expected for every update to be heavily scrutinized.
In the end, at some point you either have to inspect every line of code yourself or trust others to have done it for you. Package managers fall into the latter category.
Instead of pasting it in terminal, I opened a new tab and read it. There’s maybe 200 lines, most of which aren’t relevant to my platform. Didn’t see anything unusual.
I then proceeded to install tens of thousands of lines of code I didn’t read onto my machine.
My point? People really seem to be bike shedding this install script bit. If I was a malicious actor I wouldn’t be hiding the bad parts in the install script.
200 lines versus the actual install steps which is 1. wget the tarball, 2. extract the tarball to .local/bin, 3. done, or a few more steps to add the desktop file.
That's an incredibly weird response to a comment primarily concerned with the user experience of vendoring software on Linux. Not only does it not engage with my comment but it also virtue signals quite a bit, don't you think?
It is incredibly ironic when looking at your post history that you state that you have "been involved on[sic] [...] the nuances of interface and user experience". Does my comment not meet that very criteria?
"reading before you run" eliminates all convenience of the one liner. Their linux docs are way better because it shows you exactly how to do it on a per-distribution basis. when it comes time to update the software I would prefer to know how exactly it is installed so that I can update it correctly.
Three months from now I won't remember using the script to install it. And the contents of the script could completely change. This is not a helpful take.
This is not a helpful take for you. The same method works fine for me over the last decade. Taking notes helps, having some helper scripts helps. If one’s invested in a technology, one finds a way to remember.
Debian packages are often old. Hence people found a way around.
> You just described how the script is less convenient to meet the preferences of the commenter you replied to.
Well… no. The person I reply to doesn’t say anything about preferences. They want to know how to update the software, the script is the best reference.
You know nothing about what I do. Keep editing code. You just grind on an infrastructure brought to you on a silver plate? Like an editor is the only thing we have fuck around with.
I am less concerned about it being malicious and more concerned about it doing something I do not want re: how the software is installed. Installing software from the distributions package manager is always preferred to doing something manual. When it comes time to update the app, I would prefer to not have to do that in a roundabout way.
Fortunately docs go into better detail, https://zed.dev/docs/linux
I'm on Debian anyway so who am I kidding expecting this to be in apt :D