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?

  • I couldn't find any reference to ~/.local in the FHS -- just /usr/local, (pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY)
    – Jeff Schaller
    Commented Jan 30, 2016 at 13:16
  • @JeffSchaller You're right, I've changed the tag to XDG.
    – pipe
    Commented Jan 30, 2016 at 15:19
  • 1
    Be careful that ~/.local/share is used for per-user application data. Why not create a ~/.usr and install things there!
    – cylgalad
    Commented Jan 31, 2016 at 8:53

4 Answers 4


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
    Commented Jan 31, 2016 at 2:34
  • 1
    "because not many people need to do it" -- nah, it's extremely common on clusters. It's puzzling that, after decades, Linux still doesn't have an established standard convention for doing this. Commented Jul 28, 2022 at 7:27
  • Not really. You say decades, but regular users having accounts on clusters wasn't a common thing even one decade ago. There should probably be some kind of convention for this, but there's security issues involved and that always complicates matters. Honestly, I expect we'll find people using containerized user accounts as a common thing before we see a common convention on home directory software trees. I miss the simple days when you'd just pester your sysadmin to upgrade Perl. Commented Jul 30, 2022 at 5:32
  • @JeffSpaulding I can assure you that it was common in my field (scientific computing, more specifically genomics). What security issues are you imagining that are not adequately addressed by existing POSIX file permissions? Commented Aug 3, 2022 at 12:55
  • It's the lack of POSIX permissions that is (part of) the problem. If you're compiling your own software (or worse, downloading executable code) in your home directory, then your user is the file owner. There's much more to it than that, though, such as library and $PATH order. I'd recommend discussing the topic with a UNIX security expert if you're curious. Commented Aug 5, 2022 at 7:02

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.


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.


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. Commented Jan 14, 2020 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
    Commented Jan 21, 2020 at 9:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .