The traditional approach is to create either a single dotfile, or a single dot-directory, directly under the user's home directory, named for your application. Thus
~/.thromblemeisteradmin (which could be a plain file or a directory containing any number of files). Sometimes a directory has a name suffix of
.d, but that is redundant if there's only a directory. Similarly, for historical reasons files have often had a
rc suffix; thus
procmail. If it's a directory and appropriately named, it's generally assumed to be "owned" by the respective application, but entirely possibly under the control of the user.
However, while many applications still do this, this practice is discouraged on Linux since quite some time ago.
These days, the recommended location for such data, per the Linux Filesystem Hierarchy Standard version 3.0 (authoritative standard document) and the XDG Base Directories specification version 0.8 is to, among others (the XDG base dirs specification has a more complete list and is the authoritative reference for the usage of each):
- store user-specific configuration data in an appropriately-named subdirectory of
- store relatively important user-specific data in an appropriately-named subdirectory of
- store relatively unimportant user-specific data, such as current application state or recovery files, in an appropriately-named subdirectory of
- store readily recreatable user-specific data, such as cache data, in an appropriately-named subdirectory of
Each of these will very likely appear somewhere within a subdirectory of
/home, but you can't necessarily count on that; consider
~root which is often
/root or on some systems
/var/root. Do keep in mind that the
$XDG_* environment variables might not be set; modern systems probably set them in their default configuration, but there's still the possibility that they are unset, in which case the specification provides fallback values for each.
If you really only need a single file for any of these, then substituting a file for the directory is generally acceptable; however, many applications still create a directory, if for no other reason then for future-proofing purposes. So it's not at all uncommon to see something like
$XDG_CONFIG_HOME/<someapplication>/config.ini, with nothing else under that directory. The specification also calls out things like filesystem permissions and provides examples of how to handle failures. It's not that long; if you are considering doing this, taking the few minutes to read through the actual XDG base directories specification is probably time well spent.
As an example, something like a hypothetical SSH client adhering to the XDG base dirs spec might store its configuration somewhere under
$XDG_CONFIG_HOME, host and user keys somewhere under
$XDG_DATA_HOME, and optimization data (I'm not sure exactly what that might be, but with the advent of post-quantum cryptography, who knows what might be useful?) somewhere under