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