Description of problem:
Apps segfault if $HOME isn't in the environment, because FcStrCopyFilename calls
strlen() on the result of getenv() before checking it for NULL.
# unset HOME ; /usr/bin/bluepin asd asd
Fixing the segfault with the (soon to be) attached patch is only vaguely helpful
-- apps still fail to start...
# unset HOME ;
/usr/bin/bluepin asd asd
No fonts found; this probably means that the fontconfig
library is not correctly configured. You may need to
edit the fonts.conf configuration file. More information
about fontconfig can be found in the fontconfig(3) manual
page and on http://fontconfig.org
Setting HOME to a bogus nonexistent directory makes the application work fine;
it's not that the directory is actually required.
Created attachment 91316 [details]
Just out of couriousity - and to know how important a "functional"
fix is, when would programs be running without $HOME in the environment?
Is this a situation when using getpwuid() would work?
Not sure how common it'll be -- the example is a GUI dialog box invoked from a
deamon (it's in the bluez-utils package if you want to look closer) and is the
WrongThing anyway -- dbus or whatever will obsolete it soon, hopefully.
If it didn't work with 'HOME=/somebogusdir' and actually _needed_ the home
directory, I'd suggest that it isn't worth fixing. But since it does work like
that, it seems like it might be fairly simple to make it work with !HOME.
I've worked around it in bluez-utils for now, just by setting HOME to "" in the
Fixed upstream as of 2003/02/06, tests OK with fontconfig-2.2.1-1