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.
this post was submitted on 25 Jun 2023
814 points (100.0% liked)
Technology
37737 readers
708 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
Or use inotifywait from inotify-tools. It logs acces 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?
load more comments
(1 replies)
This is the way.
load more comments
(3 replies)
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.
load more comments
(1 replies)
I'd take it a step further and say that all programs should be completely self-contained in one folder.
That doesn't work well for... well, most software I can think of.
Games: I do not want to backup the entire folder to ensure I have my save files. Modern games are huge. I want my saves to be located somewhere easy to get to (for the average user) and be quick to backup, without having to go in and cherry-pick specific files.
There was a good trend of using Documents/My Games, but sadly that seems to have fractured and now there's also Saved Games, savegames, and some software has moved to using %appdata% or just storing saves in the game install location. There's no consistency, it's a real pain in the hole.
DCC software (Blender, Photoshop, whatever): user preferences and config files. Again, I idon't want to backup the entire software, as I'm likely to reinstall it from an official source when migraing/reinstalling to ensure I have the latest updates. However I do want to be able to backup my preferences or plugins easily.
Any software that allows users to customise it: let me backup those preferences without cloning the entire app.
I do wish there was a standardised folder struture for user data, but it's 2023 and the chances of getting Windows/Max/Nix to agree upon and comform to a generic structure as sadly. The only thing I can think of that's the same across platforms is the .ssh folder.
I don't think Win/Mac/*nix need to use the same structure across different OSs, but it would be nice if applications used conventional paths for within each of those OSs.
load more comments
(6 replies)
This is the big thing I miss from my “pre-Unix” Mac days. In OS9 and earlier, apps were self contained, and didn’t spread their garbage everywhere. You deleted an app, you deleted all the app. Granted, there was a tradeoff (the parade of conflicting control panels and extensions you had to manually diagnose when your machine went sideways) but I never understood why in the Windows and Linux worlds devs would code so sloppily. Who told that dev my Documents folder is where their nonsense needs to go? That Documents folder is for my use, not theirs.
Still salty after all these years
I use linux and this annoys me to, every program just spams my home directory with config files, even though .config and .cache exist and are the standard
Programming tools/IDEs seem especially egregious.
.android
.cargo
.choosenim
.conda
.emacs.d
.nimble
.npm
.rustup
load more comments
(1 replies)
load more comments
(4 replies)
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.
load more comments
(1 replies)
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_HOME and 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_HOME and $XDG_DATA_HOME?
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.
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.
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
If it's not in /etc it should be in the directory the exe file is located.
~/.config is the non-root version of /etc these 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_HOME for configs and $XDG_STATE_HOME for state. If they aren't available, use the defaults (./config and .local/share).
But what about .local/, or .appname/? It's just a mess
~/.local is the non-root version of /usr. By .appname do 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.
load more comments
(1 replies)
load more comments
(2 replies)
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.
(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 lsof command. 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_program to 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
load more comments
(6 replies)
@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.
load more comments
(1 replies)
It puts it's Configs in /etc/ or it gets the hose again.
view more: next ›