Everything that uses configuration files should report where they’re located
June 24, 2023
Here’s something that I’ve come to strongly believe as a system
administrator: if a program uses a configuration file (or several),
it should have an obvious command line way to find out where it
expects to find that configuration file.
As a system administrator I deal with a lot of different programs
that use configuration files, most of which have their own normal
locations for those files. Sometimes this is a system wide location,
sometimes this is a per-user location, and some have both. I’m sure
that all of these locations are obvious to people who deal with the
particular program regularly, but I don’t (always) do that. Some
programs I touch only rarely, and others can be built differently
on different systems. Naturally, I don’t remember where their
configuration files are located on this system today, so I wind up
having to find this out somehow. Ideally I’d like to avoid scanning
all the way through the manual page or other documentation for the
program to find out, because that’s slow and annoying.
(One of my ways around this is to ask the system’s packaging system
what package the program comes from and then look through the list
of files and directories owned by that package to try to find
something likely. Sadly, this doesn’t always work.)
What I want is for programs to have a straightforward way of reporting
what (and where) their configuration files are. In order to be
genuinely straightforward, this needs to be either reported in the
standard help output for the program (eg, in ‘program –help’) or
the special way to find out should be explicitly mentioned in the
program’s standard help output. Other more obscure options don’t
really cut it.
When reporting these locations, programs should fully expand things
and report the location they’ll use given the current settings of
things like environment variables, although I will give programs a
pass on not expanding $HOME to its current value. This is especially
relevant for things like per-user configuration files that follow
the XDG standard, because the XDG
configuration location is affected by environment variables. This
is one reason programs may want to report this through a separate
option or commands.
I award a semi-honorable mention to programs that will report this
information but hide the details so deep in their help that you’ll
never find it unless you’re already reasonably familiar with them.
Sadly, Go’s toolchain is one such system; if you don’t have some
idea where to look, you’re probably never finding ‘go env GOENV‘
on your own.