Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am building command line application, and I have a need to save some temp data to files. I do not know where is convention for applications to store their cache on unix based systems (in this case Ubuntu 12.0.4)?

share|improve this question
up vote 7 down vote accepted

"Unix based systems" is far too general a category to make any kind of generally-applicable determination that will apply to all Unix based systems. The problem is that the filesystem structure (and the "proper" / "conventional" place to put things) is so wildly different between different flavors of "Unix" (if you can even call it that) that you pretty much have to handle it on a case-by-case basis.

A few examples:

  • On Ubuntu, 64-bit libraries go into /usr/lib or /usr/lib/x86_64-linux/ and 32-bit libraries go into /usr/lib32
  • On Fedora, 64-bit libraries go into /usr/lib64 and 32-bit libraries go into /usr/lib
  • Fedora has no notion of /lib or /bin anymore (they are just symlinks into the equivalent /usr directories)
  • Most Linux distros prefer to install user-installed software (that is, software not provided by the package manager) in /usr/local/ (with lib, bin, etc, var, and so on within /usr/local/)
  • Many Linux distros use /var/cache for cache, although if it's "transient" (doesn't matter if it gets lost), it can be stored in /tmp
  • Some "app in a folder" type applications store everything in a subdirectory of /opt (especially clickwrap installers)
  • Some apps just install into a subdirectory of the user's ~ directory (usually /home/username)
  • On Solaris, I've seen /srv used similarly to /opt, or sometimes /srv is the www-root

The answer is that the canonical, socially acceptable, well-integrated convention for where to store anything on any operating system, whether it's a distro of Linux, BSD, Solaris, HP-UX, etc. is dependent on the exact circumstances. Specifically:

  • How is the package distributed?
  • Does the user require root access to install it?
  • Does the package depend on or integrate directly with other packages already on the system, e.g. a plugin or add-on?
  • Is the package going to be integrated into the distribution's upstream repositories, so that users can use a command like apt-get or yum to install it directly without downloading an installer off a website?
  • Will the software have separate configuration for each different user who operates the computer?
  • Will the software have global configuration settings that should only be modifiable by the administrator (root)?
  • Does the software need to integrate with the init system (e.g. to start on boot)?

There is no straight answer for this without considering all the factors. However, for Ubuntu 12.04 specifically, if you are building your package into a .deb file to be distributed in a PPA or for submitting to Ubuntu's own package repositores (main or universe), I would recommend that cache should be stored in /var/cache. But that is only for Ubuntu and you should certainly not apply the assumption that every distro or Unix-based OS will consider this acceptable.

Furthermore, if there are no advantages to saving the cache data across boots of the system, I think it could also belong in /tmp.

Note that you are going to run into these pathing convention problems for every type of file that your program uses: shared data, executable files, libraries, help files, images, sound, web pages, and on and on. So I have to wonder, if you are asking about cache files, how you are planning to handle the other file types. Are you just making naive assumptions and hoping that no one disagrees with you? If you haven't read any Ubuntu docs or standards suggesting where to put them, it is a bad idea to just assume one thing or another. For example, always sticking libraries in /usr/lib could be a mistake, as depending on the situation they may belong elsewhere.

Additionally, as a software developer, I think the most responsible thing to do is allow the end-user to decide where to put their files. You can set defaults, but users (and distributors) can and will customize the build to fit with their distro.

The easiest way to do this is to build your program using GNU Autoconf. Autoconf is a build system where the user can pass command-line arguments to the build script to change the paths of the various "directory types" away from the defaults. Almost every distribution has a build script for every Autoconf package that sets the distro-appropriate conventional directories for each type. They even specifically have a directory type for cache: sharedstatedir.

share|improve this answer
First thank you very much for your answer, very detailed indeed. Nature of the application (ruby) is to cache API calls that serve static content. This is ruby application, and from what I have read in your answer place for my disk cache would be /tmp folder. Answers to your questions would be (download, no, no, no, no, no,no). Probably seems normal for most people to conclude is /tmp but I am new to unix systems and ubuntu os based conventions are unfamiliar to me. This opens interesting idea for gem to allow agnostic disk caching (user agnostic). Thanks, +1 from me. – Dolphin Sep 14 '12 at 15:03
Note that the ruby gem system as installed on most Linux distros has a very specific directory where the gems are installed by the gem tool. However, it would probably not be appropriate to create files at runtime within the same directory where your application is downloaded by the gem. On the other hand, if you're running the app as a user, you need a directory that's read-write for users, and that means either changing permissions (which requires even more system integration work at install-time such as creating a group etc), or using a global read-write directory, e.g. /tmp. – allquixotic Sep 14 '12 at 15:07

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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