richard at tartarus.org
Thu Sep 4 17:11:19 EEST 2003
Carl Worth wrote:
> On Sep 4, Jaap Karssenberg wrote:
> > Following the spec both 'XDG_DATA_HOME' and 'XDG_DATA_DIRS' are searched
> > by some app. Now if I want to force the app to search just _one_ dir I
> > set 'XDG_DATA_HOME' to that directory, now my dir _and_ the default dirs
> > for 'XDG_DATA_DIRS' are searched. If I could set 'XDG_DATA_DIRS' to an
> > empty string, I would be sure only my dir is searched, but the spec
> > prohibits this by specifying that the default should also be used for
> > "set but empty" vars.
I'm not sure that all users know the difference between:
$ unset FOO
I know that I used to assume the two were identical, ie that an empty
variable was equivalent to an unset variable, until I looked into
writing code to read environment variable values. This was because, for
example, "$foo" expands identically in bash whether the variable "foo"
is set to empty, or is unset.
> What's the motivation for the two separate variables? Since the
> variables can accept a list of values, it seems that the desired
> control could be achieved much more simply by just having a single
I'm not sure, but I'd guess that the idea is that users can change where
they want their personal settings read from, without having to
explicitly add the defaults.
ie: if I want to store my personal data in .mydata/, but still read from
the default locations as well, I can simply set $XDG_DATA_HOME to
$HOME/.mydata/, rather than having to set, say, $XDG_DATA_PATH to
> Unless I'm missing something... (in which case perhaps the
> specification could use a little more language to fill the hole).
I agree that it could do with having some discussion of the motivations
More information about the xdg