basedir spec
Geoff Youngs
g at intersect-uk.co.uk
Thu Sep 4 18:23:48 EEST 2003
On Thu, Sep 04, 2003 at 12:51:36PM +0200, Jaap Karssenberg wrote:
> On Thu, 4 Sep 2003 10:07:47 +0530 Biju Chacko wrote:
> > And what would an empty var mean? Logically, an application cannot
> > look for a datafile in the path "", so it would have to fall back to
> > a default -- which is what the standard states.
> >
> > Since this is fairly obvious, I guess you must have somehing else in
> > mind. Could you clarify please?
> Thank you for your confidence :)
> 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.
> Setting the search path to just one dir is very usefull for testing
> purposes. Also it is not unthinkable that a user _only_ wants to use
> his own data dir, and non of the defaults provided by the admin.
[...]
It would actually simplify most implmentations - ones in C would only
need to check the return value of getenv(), etc.
The only possible concern that I can think of is a scripting language
binding that doesn't/can't tell the difference between an unset
environment variable and a blank environment variable.
But I can't think of any.
It might be safer to use a value such as "none" (or whatever), but
change to specification to specify that only absolute pathnames should
be considered valid within the XDG_* vars (which it might be worth doing
anyway - unless the program is part of a ROX-style relocatable
application directory, it probably shouldn't be looking for normal data
in paths relative to the CWD. And if it is part of a relocatable app
dir, then it should probably be using APP_DIR, rather than XDG_*).
TTFN,
Geoff.
More information about the xdg
mailing list