> That sounds good, but doesn't work for e.g. XDG_RUNTIME_DIR, that you
> cannot easily derive from HOME.
I meant `$XDG_*_HOME`, like `$XDG_CONFIG_HOME`, not `$XDG_RUNTIME_DIR`.
Runtime dir stays mandatory anyway.
What I want your opinion on is how we should handle problem 1:
a) Introduce a new variable usable in the config as `$HOME`,
so config can use the paths relative to home:
`storelist=${HOME}/.config/s6/sv`
b) Add a fallback for every `$XDG_*_HOME` variable(not `$XDG_RUNTIME_DIR`).
On Wed, Sep 23, 2026 at 10:08 PM Laurent Bercot
<ska-supervision_at_skarnet.org> wrote:
>
> >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:50:07 CEST