Not at all. You can read `XDG_CONFIG_HOME` to know where the config path actually is.
Or, if you're lazy, just hard code to `.config`.
I think maybe you are unfamiliar with how paths work on *nix.
All paths are virtual, meaning they are provided by something. Part of the "everything is a file" nix thing. Normally, files are provided by your file system, which (usually) examines stuff like inodes and partition bits, but they are also provided by processes, sockets, pipes, etc.
Everything is a file. So .config is just another "file", if you move the whole disk directory aside, it still exists, provided by the driver.
So your program has to do exactly nothing, other that use either a path, or maybe the env var (maybe useful if you move the physical location of the folder, e.g.)
> I like environment variables, but developers/operating systems have trouble using them well.
So then read `XDG_CONFIG_HOME` to find the "virtual" path where the driver will mount the config "virtual" path that could have just been referenced directly in `XDG_CONFIG_HOME`?
> All paths are virtual, meaning they are provided by something.
As opposed to not being provided by something? That's nonsense and even if it did make sense, if ALL paths are virtual, the distinction is meaningless.
Also, you're taking "everything is a file" too literally.
> that could have just been referenced directly in `XDG_CONFIG_HOME`?
It is referenced directly though...
> That's nonsense
What exactly are you asserting to be nonsense? Exactly nothing I said about paths on unix is nonsense, please provide a specific example of what you think is nonsense.
Well, ok, whatever. This is a fairly trivial thing to discuss...
Now you have even more complexity. Programs will have to know where this "virtual" path is unless you're suggesting it should be hard-coded.
> on *nix, all paths are virtual anyways
What does this mean?