On Mi, 02.05.18 21:13, Lennart Poettering (mz...@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 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg