Can't update preferences and can't get rid of Welcome dialog in Gnucash 2.4.7 (OS X 2.6.8)

[prl]

On 8/08/11 2:08, John Ralls wrote:
> On Aug 6, 2011, at 10:00 PM, prl wrote:
>
>> On 3/08/11 23:54, John Ralls wrote:
>>> ...
>>> The interesting thing here is that there aren't any errors from GConf when you did use the launcher script. Did they show up in Console? I suppose ~/.gconf is still unpopulated.
>> I was sure I checked whether .gconf was populated after each change of gconf/2/path and then running Gnucash. However, when I just looked at it, I saw that it was populated on 3 Aug when I was last testing changes in gconf/2/path. I've also found that links in /Volumes, where you suggested I make a link to my home directory, are deleted on reboot. That may have led to some of the confusion on my part, because I was rebooting after changes to gconf/2/path, ironically because I thought that it would be cleaner. Too clean, apparently.
>>
>> I've since moved the link to '/' (ugly, I know, but it will do for now), and ~/.gconf now gets populated, things like "last file opened" are saved and used correctly, all in all it seems to work as it should and the link stays put. Thanks for your help.
>>> What does "echo $HOME" print?
>> Cambyses:~ prl$ echo $HOME
>> /Volumes/Cambyses User/Users/prl
>> Cambyses:~ prl$
>>> What did you edit gconf/2/path to say?
>> I've tried the following in gconf/2/path:
>>
>> xml:readwrite:$(HOME)/.gconf
>>
>>     Original setting. Doesn't work with spaces in $HOME.
>>
>> xml:readwrite:"$(HOME)/.gconf"
>>
>>     After the style of the setting
>>     include "$(HOME)/.gconf.path"
>>     Doesn't work with spaces in $HOME.
>>
>> xml:readwrite:"$(HOME)"/.gconf
>>
>>     As suggested by you. Doesn't work with spaces in $HOME.
>>
>> xml:readwrite:/Volumes/prl/.gconf
>>
>>     After doing
>>     ln -s ~ /Volumes
>>
>>     Works while link exists, but the link is deleted at boot time.
>>
>> xml:readwrite:/prl/.gconf
>>
>>     After doing
>>     ln -s ~ /
>>
>>     Works, but is a bit ugly.
>>
>> So, now I have a workaround. Thanks.
>>
>> By the way, on the topic of spaces, I see that the /Applications/Gnucash.app/Contents/MacOS/Gnucash shell script ends with:
>> $EXEC "$bundle_contents/MacOS/$name-bin" $EXTRA_ARGS $*
>>
>> Shouldn't that be:
>> $EXEC "$bundle_contents/MacOS/$name-bin" $EXTRA_ARGS "$@"
>> so that spaces in any arguments given to Gnucash are passed to Gnucash-bin without reinterpretation by the shell? This is important, for example, if the FILE path for --add-price-quotes=FILE contains spaces.
> Good that you've got it working. Could you file a bug against GConf complaining that it doesn't handle paths with spaces in them?

Hi, John. Before I try logging a bug against GConf, I'd like to try to 
try to find out more about where and why the problem is happening. I've 
tried turning on logging in gconfd by setting the environment variable 
GCONF_DEBUG_OUTPUT in the Gnucash script and adding a logging entry to a 
file for user.* to /etc/syslog.conf, but I haven't been able to get any 
debugging info out of gconf. Any suggestions?

> I think we tried that last year when we were trying to do just what you're asking about and it caused other problems without fixing the file path problem, but my memory might be wrong. Did you try it and get it to work?
>

You're right: just changing $* to "$@" isn't enough. The code that 
shifts out the first argument if it starts with "-psn_" also fails. It 
can be fixed in the Gnucash script by changing:

     if [ x`echo "x$1" | sed -e "s/^x-psn_.*//"` == x ]; then
         shift 1
     fi

to

     if expr "x$1" : '^x-psn_' > /dev/null; then
         shift 1
     fi

making use of the not-so-well-known regular expression matching in 
expr(1). Alternatively, it can also be fixed by using a pipeline of the 
echo and grep. I have tested that both those approaches work with 
--add-price-quotes=FILE where FILE contains spaces. Of course, $* needs 
to be changed to "$@" as well.

Cheers,
Peter