basedir spec

[Richard Boulton]

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:
$ FOO=""
and
$ 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
> variable.

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
$HOME/.mydata/:/usr/local/share/:/usr/share/

> 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 
added.

-- 
Richard