Not really: unless you inspect ~/bin/hr before using or updating it, both boil down to the same thing.

Nope, "curl |bash" is worse, because (a) if there's any network problems when downloading it might split a command in half. like "rm -rf /tmp/$PID". What happens if the bytes after the first / are dropped? and (b) at lease you have the option of reviewing it when you download the script.

This doesn't contradict at all what I said. (See http://idioms.thefreedictionary.com/boil+down+to)

So does any package installation where you don't read the source. Piping curl into the shell is bad because the server can choose to serve malicious content to your curl that it didn't show in the browser.

> Piping curl into the shell is bad because the server can choose to serve malicious content to your curl that it didn't show in the browser.

And to head off objections, Piping curl into the shell does not leave any record on disk, unlike the "download .... ./execute" workflow in which it is trivial and natural to insert "and take a quick peek at it too".

Edit: And in the best case scenario, where the script delivered by curl is perfectly innocent, it is still a bad idea since you are left with no authoritative record of what was done. You could run curl again in the future, but that assumes that the same version is delivered, or that the file is still there at all.

Not quite true. Not all packages are created equal. For example anything from PyPI, npm, Ruby Gems, and Homebrew is suspect. On the other hand Debian/Ubuntu or Red Hat repo's are likely much more trustworthy since they have actual paid trusted maintainers who review the source code.

Not sure where you got that impression. In lots of cases, package maintainers are people who use the software and are volunteering their time to bundle it up with the necessary bits to put in a distro repo. The same is true of language-specific repos or homebrew.