views:

180

answers:

6

Coming from Windows background here.

Is it an acceptable practice for GUI Linux applications to store their data files (not user-specific) at hard-coded locations (e. g. /etc/myapp/stuff)? I couldn't find any syscalls that would return the preferred directory for app data. Is there a convention out there as to what goes where?

+5  A: 

/opt/appname/stuff according to the Linux Filesystem Hierarchy Standard

Your distribution's packaging system likely provides ways to handle common installation paths. What distribution are you using?

Joe Koberg
Developing on Debian, but I wanna target as many desktop-based distros as I can. Thanks for the link.
Seva Alekseyev
Check out the Debian Developer's Corner: http://www.debian.org/devel/
ssahmed555
The /opt/appname/stuff standard is not widespread, AFAIK. /etc/appname/ is much more common.
leonbloy
The doc says etc is for configs.
Seva Alekseyev
Seems like there's plenty of standards to choose from! My guess is, as long as you are writing files with unique names, it doesn't matter which you choose as long as the package system knows how to install and uninstall it. And in those cases where you must write to some global configuration (e.g. adding a stanza to httpd.conf), methods have usually been devised on the big distros to allow you to write a unique file somewhere like a `conf.d` directory.
Joe Koberg
+4  A: 

Generally speaking, yes there is a convention. On most Linux systems, application configuration files are typically located at /etc/appname/. You'll want to consult the LSB (Linux Standard Base) and the Linux FHS (Filesystem Hierarchy Standard) for their respective recommendations.

Also, if you are targeting your application towards a specific Linux distro, then that distro vendor probably has their own specific recommendations as far as packaging and related-conventions are concerned. You'll want to look at your distro vendor's developer pages for more information.

ssahmed555
A: 

Under Linux, only the basic services (opening a file, doing networking and interprocess communication etc) are provided as system calls. The rest is done using libraries.

If you are coding a GUI application, you should look into your toolkit's documentation to see if it provides a mechanism for managing defaults. Both KDE and Gnome have one for instance.

DomQ
+3  A: 

Configuration files for processes with elevated privileges are generally stored in /etc. Data files for processes with elevated privileges (Web Server, Mail Server, Chat Server, etc.) are generally stored in /var. And that's where consistency ends. Some folks say you start with the location to store them (/etc|/var) then have an appname sub-folder for your app, then continue from there as necessary.

If you're not a system daemon with elevated privileges, your only consistent choice is a dot directory in the launching user's home directory. I think the Free Desktop Standards (XDG) specify ~/.config for per-user configuration, and ~/.cache for replaceable static and/or generated data you need to save.

Looking at my Home Directory, a few key dot directories I have are: ~/.cache ~/.config ~/.irssi ~/.maildir ~/.mozilla ~/.kde ~/.ssh ~/.vnc

[edit]
While not a syscall, the XDG specifications I reference are at http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

VxJasonxV
+2  A: 

There are certain conventions.

  • System-wide, readable/editable (text-based) configuration files go in /etc/appname/.
  • System-wide, per-machine binary data files that change (eg. binary databases) go in /var/*/appname/ - /var/cache/appname/, /var/spool/appname/ and /var/lib/appname/ are the most common.
  • System-wide binary data files that could notionally be shared between machines (eg. things like graphics and sound files) go in /usr/share/appname/.
caf
Gotta love those conventions. Pick the one you like best!
Seva Alekseyev
+1  A: 

The full paths that Unix/Linux/GNU applications use to store config files and other data is usually set when an application is configured prior to compilation. These paths then get hard-coded into the compiled binary (you can see examples of this by running strings(1) over some existing executables).

That is, these types of paths are build-time configurable, not run-time configurable by default. Many apps will support command line options to specify where a configuration file is, and that configuration file will usually contain paths for other application resources. This allows an application to run with minimal configuration (built-in paths) but also allows a site to customise the paths completely.

camh