basedir spec
Jaap Karssenberg
j.g.karssenberg at student.utwente.nl
Fri Sep 5 00:59:42 EEST 2003
On Thu, 4 Sep 2003 23:03:00 +0200 Waldo Bastian wrote:
: See https://www.redhat.com/archives/xdg-list/2003-May/msg00085.html
Hmm, maybe an empty DATA_HOME var should cause an error, but an empty
DATA_DIRS var is only used for reading.
To avoid programming errors as described in the referred mail, you could
supply an utility library that also handles the default values for the
vars. (I made such a lib for perl all ready because I needed it for my
mime-info module. )
: For testing you can set it to some /none-existing-path:
But what would happen if someone actually had a dir called
"/none-existing-path", for example because some other app tried to use a
non existing dir and by accident made it ? Now I can think of some
pretty random file names, but theoretically that requires me to know all
used filenames for all future time :)
Or to put it differently, it's a dirty hack, not a solution.
: Unsetting variables may be difficult in some situations. No idea if it
: can be cured by additional autoconf stuff but:
:
: "Various Unix variants (DGUX, HPUX, QNX, ...). POSIX.9
: (bindings for FORTRAN77). POSIX.1-1996 did not accept clearenv() and
: putenv(), but changed its mind and scheduled these functions for
: some later issue of this standard (cf. B.4.6.1). However, SUSv3 only
: adds putenv(), and rejected clearenv()."
Not sure what problem you are pointing at here, do you mean that not all
flavors of unix support a system call to unset environment vars?
I looked into IEEE Std 1003.1, 2003 Edition (POSIX) and it defines
"unsetenv()" as a mandatory function. Of course not all systems are
POSIX compliant, but that never stopped me before.
--
) ( Jaap Karssenberg || Pardus [Larus]
: : http://pardus-larus.student.utwente.nl/~pardus
) \ / (
",.*'*.," Proud owner of "Perl6 Essentials" 1st edition :)
More information about the xdg
mailing list