${HOME} vs. g_get_home_dir ()

[Ivan Shmakov <oneingray@gmail.com>]

	I do remember filing a bug or two against packages that refer to
	the getent () data to find the user's “home” directory instead
	of using the HOME environment variable.

	The environment is the preferred place to check for this kind of
	things: it's (usually) under the full control of the user, and
	it's quite possible to run several instances of a single program
	using different environments (with different executable file
	search PATH's, locales, time zones, etc.), which occasionally
	turns to be an immense aid to debugging.  (Want to use the
	all-defaults configuration for a program?  Just start it like:
	$ HOME="$(mktemp -dt -- foo.XXXXXXXX)" foo)

	Now, Glib has g_get_home_dir (), whose description reads [1]:

--cut--
    Gets the current user's home directory as defined in the password
    database.

    Note that in contrast to traditional UNIX tools, this function
    prefers passwd entries over the HOME environment variable.
--cut--

	I believe that this behavior is buggy.  There's even a (yet
	unresolved) bug report [2] against Gimp due to this behavior,
	and my guess is that there may be quite a few packages more
	affected by it.

	While I understand some of the concerns regarding the “Unix”
	behavior (also at [1]; quoted below), I'd like to note that the
	software which both relies on g_get_home_dir () /and/ stores its
	files under a subdirectory of the home directory returned (which
	is, arguably, a common practice), is also likely to run into
	issues should that /subdirectory/ be made non-writable (or
	non-readable), and the current g_get_home_dir () behavior is not
	a safeguard against it.

	Therefore, I'd like to propose for this behavior to be changed
	to match the usual Unix conventions.  To address the only
	concern listed in [1] I deem valid, I'm also asking that the
	value of HOME be disregarded, unless it points to a directory,
	which is readable, writable, and owned, by the user.

	Unless there be objections (or Glib be quickly patched), I'd be
	filing a bug report against libglib2.0-0.

	TIA.

--cut--
    One of the reasons for this decision is that applications in many
    cases need special handling to deal with the case where HOME is

    Not owned by the user
    Not writeable
    Not even readable
--cut--

[1] http://developer.gnome.org/glib/2.28/glib-Miscellaneous-Utility-Functions.html
[2] http://bugs.debian.org/453711

-- 
FSF associate member #7257