[PATCH 0/2] XDG basedir bin dirs

Lennart Poettering mzkqt at 0pointer.de
Wed May 2 19:42:44 UTC 2018


On Mi, 02.05.18 21:13, Lennart Poettering (mzkqt at 0pointer.de) wrote:

> So yeah, Allison also suggested that having a single "XDG_PREFIX" env
> var would have been the much better option, rather than have
> individual ones. Now, that ship sailed pretty much, but that's not
> reason enough to go for XDG_BIN_HOME really. I mean, "~/.local/" is
> hardcoded as fallback prefix into the spec, so we should just accept
> that here too, and admit that making this individually configurable
> wasn't the best of ideas. I mean, making the searhc paths dynamically
> configurable using an env var by all means made sense, but the "home"
> dirs? i am not convinced...
> 
> But dunno, I am not feeling too strongly about this, but it appeared
> to me that just not doing an env var here was the best way to get this
> in quickly...

So here's a strong reason for not having XDG_BIN_HOME: because $PATH
is not designed to refer to other env vars, it expects literal
paths. After all, for XDG_DATA_DIRS (and similar for the other search
path env vars) the basedir spec says that you need to search in both
XDG_DATA_DIRS and XDG_DATA_HOME, i.e. both variables are independent
of each other. But this is not how $PATH works: the variable is
implemented and respected all over the place, but what isn't listed in
it doesn't matter, hence we can define XDG_BIN_HOME as much as we
want, nobody would care, it would never be consulted.

Something similar applies to ~/.local/lib64/ and friends btw, if
people want that. For shared libraries too there's already a search
path variable defined, in LD_LIBRARY_PATH, and that too doesn't care
about XDG_LIB_HOME. Hence defining XDG_LIB_HOME doesn't make much
sense either...

Hence let's no introduce env vars that can't be supported anyway
please. 

Lennart

-- 
Lennart Poettering, Red Hat


More information about the xdg mailing list