>When some `XDG_*_HOME` variable aren't set, I get this:
Right, there needs to be a fallback.
>a) Add another interpretable config variable for `$HOME`, that can be
>set in the config instead of XDG variable usage.
>Resolve `$HOME` like this:
>Get it from env, fallback to `getpwuid(getuid())` when it isn't set.
That sounds good, but doesn't work for e.g. XDG_RUNTIME_DIR, that you
cannot easily derive from HOME.
>b) When an `XDG_*_HOME` variable isn't set, fallback to default XDG
>paths relative to the home directory. Example:
>`XDG_CONFIG_HOME` isn't set -> resolve the home directory,
>and construct it as `/home/user/.config`.
That also sounds good and also doesn't work for XDG_RUNTIME_DIR. The
fundamental problem is that any fallback needs to encode policy, and
there are too many ways that things can go wrong to feel comfortable
adding policy here. I think it's better to avoid fallbacks altogether,
and just fail.
>For problem 2, I propose showing a simple error when **any**
>of the paths in the config is unresolvable.
Yes, erroring out on any failure to resolve is a better solution, just
like it is the better solution to problem 1.
The thing is, I want to keep it simple, and avoid writing a full parser
just for the treatment of the XDG variables. For now, a simple sed
substitution is used, which is as complex as I'm willing to make it.
Erroring out on failure requires:
- list which XDG variables are undefined
- grep the config file for occurrences of those, with or without curly
braces
- fail on match.
>I would like to submit the code myself, if/when we agree on any solution.
>If I'll propose the exact patch, can I be credited as a commit author?
You can try 😄 but I am usually pretty demanding with the exact code
that makes it in, so chances are I'll want to modify something anyway.
Especially since the necessary modification looks to be a little complex
here, with the addition of a grep call with several -e arguments and
more execline glue to the command line being built, etc.
What is certain, however, is that you'll make it into the AUTHORS file
as a contributor, if you want to give me a name or pseudonym that's a
little more identifiable than "username" with a bunch of numbers ;)
--
Laurent
Received on Wed Sep 23 2026 - 19:08:05 CEST