← Back to context

Comment by woodruffw

4 years ago

Is your account the only account that's expected to run the binary? If so, then `$HOME/bin` is a perfectly acceptable (albeit not standard) place to put it.

If you expect other users to be able to execute the program, then you should put it in either `/usr/bin` or `/usr/local/bin`, depending on whether the former is already being used by a package manager. `/opt` is generally for self-contained software that doesn't play nicely with the rest of the system, but might still be installable through the default package manager.

$HOME/.local is the equivalent if /usr/local for per-user stuff.

  • I don’t think there’s any “official” word on that (the XDG spec that defines ~/.local/share doesn’t mention ~/.local/{bin,lib} IIRC, and the traditional per-user entry in PATH seems to be ~/bin), but a fair number of people use it this way, yes, including me.

I started out using $HOME/bin, but a fair amount of stuff assumes a /usr- or /usr/local-style folder structure when doing make install, so I've settled on using $HOME/usr/bin instead, so that programs can create $HOME/usr/include and $HOME/usr/share and whatever, without trampling on stuff in my home folder.

Can't remember the last time I had a problem arranging this. If using autotools, which covers 95+% of stuff, it's usually a question of something like "./configure --prefix=$HOME/usr".

(If I want to share stuff between users, /usr/local/ is of course a better place. macOS is a bit more restrictive, so I have a separate user for this, whose /usr folder is readable by everybody.)

  • > $HOME/bin

    On freedesktop systems there's the ~/.local directory which is supposed to be a mirror of the file system hierarchy. Seems like a good place for bin, lib, include directories.

  • Yeah, it definitely gets hairier when using anything that's more than just a drop-in binary.