- cross-posted to:
- programming
- theandrocollection@lemm.ee
- technews@radiation.party
I wholeheartedly agree with this blog post. I believe someone on here yesterday was asking about config file locations and setting them manually. This is in the same vein. I can’t tell you how many times a command line method for discovering the location of a config file would have saved me 30 minutes of googling.
You must log in or register to comment.
Start your application / program with “strace” and see all the files it opens.
Also run “lsof” on a running process to see what files it has open.
Or use inotifywait from inotify-tools. It logs acces <type> to specified file/folder.
Interesting. I have not heard of this tools. But you say specified file or folder, that means you already know the file location?
You can call it recursively on
.config(for instance), and watch for specific events (creation, deletion, modification, etc). But I expect this to be expensive on really large folders and I’d avoid it if I could.Btw it’s syscalls iirc (
inotify-toolsjust exposes them)
This is the way.
I doubt that’s a linux problem. All apps store config in /etc, ~/.*rc or ~/.config
Everything else should be considered a bug (looking at you, systemd!)
Check out the Lemmy install docs
well, lemmy is a webapp.
Those usually store config in some
www/htdocs/configdir. Lemmy does aswell and offersLEMMY_CONFIG_LOCATIONto override.
What’s imho worse is how often config options or command flags don’t actually do at all what’s described in the manpage. I then have to dig into the source code once again and since you have to read through the whole behaviour it takes much longer than just looking up where the program tries to read config files.
Please - if you find such wrong docs in Open source software, submit a fix to the doc. It’s as important as normal bugfixes.
I mean, that’s sort of what xdg is intended to accomplish, with making $HOME/.config be the place, but it’s kind of up to the individual software developers to comply. (Yes, I know, this doesn’t really apply to Windows/Mac OS) But yeah, it would really be nice if configs/config locations were even remotely standardized.
There’s also $HOME/.local/share for ‘static data files’ as part of XDG.
which is not config files. ~/.local is just user specific override for /usr
What I find more frustrating is undocumented environment variables to override config locations.
The amount of times I’ve had to dig through the source code for a CLI to find an environment variable to force the config somewhere should be zero. But it’s not.
This drives me freaking bonkers. A lot of times libraries tend not to expose the env var to discourage its usage but IF YOU MADE IT IN THE FIRST PLACE YOU HAD A USE CASE FOR IT.
I genuinely do not like apps using environment variables for config if they aren’t running in their own contained environment. It makes me uncomfortable.
I guess the difficulty here is that sometimes that decision is made by the package manager, not the developer. You’ll see Debian distros using a different location compared to a red hat one, while Mac OS is again different, so it might be hard for a developer to tell you where it is.
Still, some kind of universal CLI flag that tells you where the binary/service looks for configuration would be a great idea.
For Linux distros everything should use
XDG_CONFIG_HOMEand distros should start refusing to package anything that doesn’t.It would be huge if a distro like Fedora did that
And also: where it found the config file it is actually using at the moment. This would cover the 90% of the cases in which you just want to change a single Key to a different value or something or so…
It would be amazing yeah, standardising all user config files in the $HOME, and maybe etc/ or an default, non usable, user profile to store the original versions, in case of a bad config or corrupted file would save so much time debugging stuff.
Like
$XDG_CONFIG_HOMEand$XDG_DATA_HOME?
Sadly, what we seem to have over and over is https://xkcd.com/927/
It’s getting better though
The XDG Base Directory standard has kinda sorta been doing that; and I like it. Not everything supports it; and it’s not perfect, but at least it’s better than the wild west that application configs used to be.
GoboLinux kind of solved that problem but it hasn’t been updated in years.
take a look at NixOS
Does the nix configuration file contain also the config files of the programs within it?
Mixed. Many folks use
home-managerto configure their user environment withnix, and you can specify config files there. However, escape hatches to use regular files not managed bynixexist to make config tweaking faster. You can specify your config file contents innix, which works well for server deployments, but for desktop use it usually ends up being a mix of seldom-changed config going in thenixdefinitions, and other things that, say, revolve around GUI tools for config tweaking (eg KDE apps) continuing to do their own thing.I haven’t met one person who doesn’t use home-manager. Maybe that’s because most people I talk to use tiling window managers and stuff like that, where you define everything in text files.
You can see my config at https://github.com/n3oney/nixus.
PC, Laptop and aarch64 server configured in one place with shared components
read the man page
The good ol’ RTFM
this is not really what the article is about.
yes you can read man page, you can find there all possible locations of config files. yet you still don’t know where config file is stored. you have to check all the possible locations.
also if there would be some standard so you can query app for its config files, you could make automated backups easily. at least much easier that now.
of course I understand this is completely unrealistic, in software world everyone will do whatever they want…
Query an app for its config files? Omg thats such a beautiful dream though. I can see it in my mind…
For real. Usually the config file locations is at the bottom, so jumping to it is quick.
And even if the program doesn’t use config files (like various gnome, xfce and other programs), it should be possible to programmatically export and import full or partial configurations.
But don’t Gnome and XFCE have CLI commands that can get and set their config values?
Maybe, but I’m not setting the option using the CLI commands. Using a separate command for every option isn’t really easy to keep updated or modify.
With Synaptic, you can show all files associated with a package. That includes config files. Saved me a lot of hassle on numerous occasions.
Yeah anything installed via a package manager, like an rpm or deb package, you can query to see what files belong to that package. Problem is they often have default config file locations, like in your home dir, where they will not ship and install files. (Though they might create them as part of a post install process)
Seriously, I’ve lost so muuuuch time just trying to find where some random program decides to store its config files. It sometimes takes me more time than actually “doing the config”
Fortunately half of apps use dconf nowadays
I don’t know if you mean on linux but in my experience I have found the bottom part of the first man page usually has a section on config file locations.
It puts it’s Configs in /etc/ or it gets the hose again.
@wet_lettuce
Should be /etc or /usr/local/etc or /opt/etc or /opt/vendor/product/etc or ~/etc.With some exceptions for historic compatibility (like ~/.bashrc)
The man page should specify where.
The exceptions should only apply for cases where XDG is not available. In any other case, the appropriate XDG directoy configured by the user should be used first.
For user-specific config files, aren’t they all supposed to be in
~/.configthese days? I’ve never heard of software using~/etc.@dan
If you do./configure --prefix=“$HOME” \
&& make && make test && make installthen you typically get ~/etc for the config files (and binaries in ~/bin)
~/.config is not part of any posix or Un*x standard I know of.
Some desktop environments do use it, but not because of any standard I am aware of.
~/.config is not part of any posix or Un*x standard I know of.
I wasn’t sure if it’s a standard or not, but a bunch of stuff store config files there. At least on one of my command-line-only systems, I see configs for htop, NuGet, ookla speedtest, PowerShell, rclone, and borgbackup in there, as well as an empty procps directory. Apparently it’s part of the XDG standard, but it seems like a decent number of non-desktop apps use it too.
(Windows) Resource Monitor, disk tab, tick the process, see what files it opens and closes.
Also the usual %programdata% and the two %appdata% find most things.
Do things stay in that list when they are not used (since they would be opened and closed in far less than a second)? If so that’s pretty cool.
If not, you can use Process Monitor to check this. That’s what I usually do.
The *nix equivalent is the
lsofcommand. This doesn’t help you finding out in which hierarchy config files are parsed when the program accesses multiple ones, which is often the case.You can use something like
strace -eopen -f -o strace.out the_programto find all files that the program tried or succeeded to open. Then you can try to find the config file(s) in strace.out.
There’s also a nice version in perftools that can be given a PID. https://github.com/brendangregg/perf-tools/blob/master/opensnoop
I was digging through the comments for exactly this, thanks!
You still don’t know which location is preffered and how get they get merged. In my experience, digging into the source is the most straighforward. But my usual problem is more that the config option doesn’t do at all what the documentation says it does.
Wouldn’t the strace.out file be in chronological order?
Yes, though if two different files allow for the same config key - you’re stuck opening both to check
And you still couldn’t be sure, could be parsed the other way around for historic reasons.
Just reading the source code (if possible ofc) is imho easier than reading.True, though I had to use strace method on closed source binaries before (zoom)
Unless it’s using the Registry for some config values.
True. That’s harder to track down.
Procmon if you’re a masochist, or do a before and after snapshot. Here’s one tool for the latter: https://www.nirsoft.net/utils/registry_changes_view.html
If it’s not in /etc it should be in the directory the exe file is located.
~/.configis the non-root version of/etcthese days. But you just have to know that, which isn’t ideal.
If you are a developer, please take a look at the XDG Base Directory Specification and try to follow it, users will be very grateful.
Short summary: Look for
$XDG_CONFIG_HOMEfor configs and$XDG_STATE_HOMEfor state. If they aren’t available, use the defaults (./configand.local/share).But what about .local/, or .appname/? It’s just a mess
~/.localis the non-root version of/usr. By.appnamedo you just mean a folder that a specific app made in your home for itself? Yeah, I never condone that. imo that’s just a badly behaving app. It should move that folder into~/.config.
Configuration for
rootis in/root/, that is,root’s home directory./etcis for system configuration, different thing.otoh, unix directory structure is far from black magic once you know it. I have yet to see an OS that does it that elegantly (leaving aside systemd)
Certainly not. Nothing should write to /usr/bin except for the package manager in FHS distros and some distros binary directories aren’t writable at all.
Well good because a program shouldn’t be writing to its config file either.
I agree. Usually I’m referring to a user installed local application. So if the executable is in your home directory likely it’s in the same directory as the exe.
