When installing software compiled from source, I normally place them in /usr/local/, which is by far the most common default in my experience, and standard practice at least on Debian and its derivatives.

Now I want to install something in my home directory, and while I could in theory create any subdirectory and place it there, I started wondering about the different options, and if there is a standard practice. I've found essentially two answers:

  • Custom subdirectory, named something like Programs, usr
  • No subdirectory, having subdirectories ~/bin, ~/lib64

I don't like either of these, and thought that since there is already a ~/.local subdirectory, why not install there? It already contains a ~/.local/share, which has come to mean a local user's private /usr/share, so it would seem very logical to install programs, creating the whole ~/.local/bin, ~/.local/lib etc.

My question is: Is it ok to install local software in ~/.local?

Why don't I find any references to this when I search google or stackexchange for places to install per-user software? To me it seems like such an obvious location that the lack of posts suggesting it means there must be a catch somewhere.

Perhaps someone who has done this can share their experience, be it positive or negative?


It's fine.

Remember, it's your home directory; you can do anything you want in there. GNOME/KDE/whatever might complain if you go around deleting .config, but anything you do in your home directory will, by definition, only affect you. Adding some directories in .local is harmless.

Putting something in a dot directory will be mildly inconvenient, depending on your workflow. How much it will affect you depends on how you navigate the filesystem and how often you'll need to do it. If it was me, I'd make a regular directory to act as a root (probably call it local or apps) and use it that way, but that's personal preference.

Where you'll run into problems is that the system isn't set up to see your directory. You'll need to adjust PATH, MANPATH, INFOPATH, and LD_LIBRARY_PATH in your .bashrc (or whatever is appropriate for your shell). There will likely be other small "gotchas" as well.

I'm willing to be that there aren't many posts here about it because not many people need to do it. If it's a personal machine, there are few reasons not to use /usr/local. Everything's already set up for it in most distributions. If you're just installing a few apps, a lot of people make directories in /opt (like /opt/blender). Solaris does this when you install a package.

The only real use case for what you're describing is for developers or people who don't have root on their machine. Most people who don't have root just ask the admin to install a program for them - they probably wouldn't know how to compile a program anyway.

  • "The only real use case for what you're describing is for developers", bingo. I pull this program from the git repository many times per day, and installing it in my home means that I can more easily automate the upgrade without having to set up special sudo rights or similar. I think I'll simply try this out. – pipe Jan 31 '16 at 2:34

The obvious reasons why not:

  • user's home-directories are often limited in size (quotas on shared systems)
  • predefined profiles often have already added ~/bin to your PATH (making it more convenient to install in that directory)
  • if you have control of the machine, installing into a shareable location works out nicely, e.g., /usr/local/bin. Your dot-directory is not (usually) shareable with other user accounts.
  • it's easier to overlook dot-directories when looking for abnormal disk-space usage. For example, the ccache mis-feature used 1Gb in my home, before I noticed it. Browsers and desktop junk are also frequent offenders (and more than 15 years into the process none deliver a suitable disk-management tool).

On the positive side: it would reduce clutter — a little. I have 55 regular directories in my home directory, as well as 91 dot-directories.


The common convention (used e.g. with some install-home targets, like for mercurial, known as hg) is to put them directly under $HOME, i.e., in $HOME/bin, $HOME/etc, $HOME/lib, and so on. This is the result of the GNUish configuration dance starting with ./configure --prefix=$HOME.


Yes you can but it will get polluted by other software installs. I use $HOME/local and modify bashrc with path like

export PATH=.:${HOME}/local/bin:${PATH}


export PREFIX=${HOME}/local

so you know what you've installed and since they are first on the path stack they will be found before the other binaries, libs, etc. When using things like configure or cmake, the prefix is easy to remember

  • 1
    (1) It’s OK to put software in ~/.local, “but it will get polluted by other software installs.”  So “I use $HOME/local …” (instead).  Huh?  What’s the difference? (2) Don’t put . at the beginning of PATH. – Scott Jan 14 '20 at 20:38
  • (1) software install config and other files into .local NONE will install into local by default (2) I always use .: in my path – Skynet Jan 21 '20 at 9:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.