Does Linux/Unix have a unified location for Application files, like "~/Library/Application Support" on Mac OS X? I'm making a Python script that will need to store permanent but changing data, and I want it to work universally.
Linux – Location of application files
directory-structurelinux
Related Solutions
/usr/local is usually for applications built from source. i.e. I install most of my packages using something like apt, but if I download a newer version of something or a piece of software not part of my distribution, I would build it from source and put everything into the `/usr/local' hierarchy.
This allows for separation from the rest of the distribution.
If you're developing a piece of software for others, you should design it so that it can be installed anywhere people want, but it should default to the regular FHS specified system directories when they specify the prefix to be /usr (/etc, /usr/bin, etc.)
i.e. /usr/local is for your personal use, it shouldn't be the only place to install your software.
Have a good read of the FHS, and use the standard Linux tools to allow your source to be built and installed anywhere so that package builders for the various distributions can configure them as required for their distribution, and users can put it into /usr/local if they desire or the regular system directories if they wish.
There are two main ways to organize files from installed software: by package, or by type.
Unix systems tend to organize program files by type: executables in /usr/bin, executables that are only useful to the system administrator in /usr/sbin, code libraries and other processor-architecture-dependent files in /usr/lib, data files that don't depend on the processor type in /usr/share, manual pages in /usr/man, miscellaneous documentation /usr/doc, etc. (This is not an exhaustive list and many variations exist.) I used the prefix /usr, but there are in fact typically three such fanouts: at / for programs that are needed at boot time (this is sometimes merged with /usr as the distinction is not always relevant), at /usr for programs that come with the operating system, and at /usr/local for programs installed manually by the system administrator.
On most Linux systems, the distinction between /usr and /usr/local is that /usr (and /) is managed by the package manager, and /usr/local isn't. So if your application is installed using the by-type structure, it should go under /usr when distributed as a package (rpm, deb, …) and under /usr/local when not distributed as a package (e.g. if it's distributed as an archive to be unpacked manually).
Configuration files typically all go in /etc because they're meant to be modified by the system administrator. If possible, have your application read configuration data from /etc and either /usr/etc or /usr/local/etc as appropriate, with settings in /etc/ overriding the ones in /usr/etc or /usr/local/etc. It's common to lump configuration data with other data under /usr/share or /usr/local/share, so you'll find that many systems don't have /usr/etc or /usr/local/etc.
The upside of the by-type organization is that files are placed where they'll be used. All executables are in the directories in the executable search path ($PATH), all libraries are in the library search path, all manual pages are in the man page search path, etc. The one limitation of this organization is that it requires a package manager to keep track of which files are installed by each package. Since most software on Linux is distributed via a package manager, most software ends up under /usr.
Another way to organize files is by package, and the standard place for that is /opt. It's typically organized as /opt/APPLICATION/bin, /opt/APPLICATION/lib, etc., sometimes with an additional level /opt/AUTHOR/APPLICATION/bin etc. Applications are free to manage their directory however they want, though; some put miscellaneous files directly in /opt/APPLICATION. This makes package management trivial (just unpack in the right place, use ls to list installed software, use rm -r to uninstall) but makes it harder to use the software: the administrator or the user need to add the appropriate locations to search paths, or to use full paths, or to create symbolic links.
Files under /opt are usually managed manually (that's the main point of this organization), but it's possible to have packages there that are managed by a package manager. For example Chrome's deb packages put it under /opt. An advantage of doing that is that Chrome is always in /opt/google/chrome regardless of how it was installed; possibly this makes cross-distribution support a little easier.
If you want the details of how applications and distributions should organize files on Linux, read the FHS.
In a nutshell:
- When building a package (deb, rpm, …), install under
/usr, with the distribution's choice of directories (e.g. for/usr/manvs/usr/share/man,/usr/libvs/usr/libexec,/usr/libvs/usr/lib64, etc.). - When installing directly (e.g.
make install), default to installing under/usr/local(with the default subdirectories: executables in/usr/local/bin, data files in/usr/local/share/APPLICATION, etc.), and do support other choices that the system administrator might make. Note that the directory where the files will be copied during installation might not be the same as the directory where the files will be used, for example due to the use of stow (see Keeping track of programs).
/opt is also a possibility in either case, but you're putting more burden on the system administrator.
Best Answer
Have a look at the XDG Base Directory Specification. In your case it should probably be
$XDG_DATA_HOME:Please note: if you are writing a daemon you should use something like
/var/lib/or/var/cache/to save your data.