The instructions at https://rclone.org/install/#macos-installation-from-precompiled-binary don’t work on High Sierra - there appears to be no /usr/local/bin folder on a fresh installation
sudo mkdir -p /usr/local/bin
This is safe to do even if the directory already exists, so it may be worth adding it as a standard instruction for the MacOS install.
Fancy sending a pull request?
My assumption was that something had changed in High Sierra where /usr/local/bin didn’t exist anymore or was somehow locked down, but it seems it just doesn’t exist on a fresh install.
Rclone is in homebrew, and that’s certainly the installation and update method with the least friction. It’s up to date too, has 1.38 already. Anyone sufficiently sophisticated to use software like rclone almost certainly has homebrew installed anyway.
Simple as:
brew install rclone
I didn’t know rclone was in brew (I’m not an OS X user).
I found this page: http://brewformulas.org/Rclone
That forumla seems to download the head version and compile it so it is equivalent to the rclone betas.
Fancy sending a PR for the docs?
Any idea how I can get in touch with the author of the formula?
The original issue to get Rclone added to Homebrew is here. Github user catap created the formula.
It's actually in homebrew-core, not a user tap. Homebrew is similar to apt or yum in the Linux world, so think of this as being in the Ubuntu main or universe repositories. Every homebrew user, which encompasses every techie using MacOS, can install rclone without adding additional repos (called "taps" in homebrew terminology).
To install homebrew, run the one-liner on https://brew.sh/, then "brew install rclone" will do the trick. After that, any time you run "brew upgrade" rclone will be upgraded alongside all your other brew packages.
Thank you - that is a very helpful high level overview of brew
I guess I probably need a section in the docs about installing rclone from 3rd party repositories, eg from brew and also for things like the rclone package in debian/ubuntu
Keeping track of every third party sounds like a losing proposition. You can’t be responsible for third-party packaging of your code. You can’t support every possible variation. You’ve got your code, your releases.
If someone creates a brew, or a PPA or a YUM repo or other magic… those people need to support those streams
(I’ve burned out on trying to support every path before).
That is true indeed!