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.

Written on 24 June 2023.
« Go 1.21 will (probably) download newer toolchains on demand by default
Why use 'TEST-NET' IP addresses in general documentation instead of RFC 1918 ranges »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat Jun 24 22:47:26 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.