>>>>> Matthias Clasen <matthias.cla...@gmail.com> writes:
FWIW, I've filed Debian Bug#688932 [1] to track this issue in the Debian GLib package. [1] http://bugs.debian.org/688932 […] > The actual commit is > Tue Mar 5 00:38:54 2002 Owen Taylor <otay...@redhat.com> > * glib/gutils.c (g_get_any_init): Where we have getpwuid[_r], use > that in preference to $HOME, and only check $HOME as a fallback if > getpwuid fails. (#2311) > And the detailed analysis leading to this change is in > http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00066.html ACK, thanks for the pointer. > I don't think anything has changed there, really. Unfortunately, this analysis only concerns the change to the HOME environment variable (or lack thereof) made by sudo(8), su(8), and usermode. The question of user changing this variable manually wasn't considered there. The point is that the software is generally made so that the system's configuration (/etc) can be overridden by user's (HOME), which, in turn, can be overridden by environment variables (FOO_WHATEVER) and, finally, command line arguments (--whatever=) or interactively (Edit → Preferences → Whatever.) This is a reasonable behavior, and though GLib deviates from it also for a reason, it really harms the operation of the GLib-based software. For instance, there's an easy way to let GNU Emacs read /net/home/jrh/.emacs (on NFS) upon initialization, instead of /home/jrh/.emacs (on local FS), like: $ HOME=/net/home/jrh emacs Moreover, GNU Bash started under such a Emacs instance will also use /net/home/jrh/.bashrc (instead of /home/jrh/.bashrc), and so will GNU Wget, or Lynx, and a sheer variety of other tools. … But not the bulk of GNOME, which will insist on using /home/jrh/.whatever, perhaps leaving the user no way to choose otherwise (sans of persuading the local passwd(5) — or the site's LDAP — administrator to change his or her account.) The other use case is that the user can always temporarily revert to the defaults by using a deliberately empty HOME (say, while troubleshooting), like: $ mkdir -- /tmp/empty $ HOME=/tmp/empty myapp Likewise, this isn't going to work for the majority of the GNOME applications. With the proposed change, these applications will behave just as the users expect them to. Furthermore, I believe that the concerns raised in 2002-March/msg00066.html would be relieved, provided that the ownership of the directory HOME points to be checked as suggested. > And it is far too late to change the behaviour of this function, a > decade later. Then, we're still having a whole lot of GLib-based applications to file bug against (as it was just suggested in [2]; and where such a bug wasn't filed already), which are then to be fixed in each of these applications separately. Is it really the better road to go? TIA. [2] news:20120927124400.ga13...@server.brlink.eu http://permalink.gmane.org/gmane.linux.debian.devel.general/176994 -- FSF associate member #7257 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list