Custom reports do not load after upgrade to 2.6.4 on OSX

[John Ralls]

> On Oct 21, 2014, at 3:44 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> On Monday 20 October 2014 12:23:12 Derek Atkins wrote:
> > John Ralls <jralls at ceridwen.us <mailto:jralls at ceridwen.us>> writes:
> > 
> > [snip]
> > 
> > > It seems that the processing of config.user isn’t setting the
> > > default
> > > path, so load is looking in the current pwd. Try changing your
> > > config.user to say
> > > (load gnc-build-dotgnucash-path(“saltant-invoice.scm”)) etc..
> > 
> > Just to be clear, this should probably look like:
> > 
> >   (load (gnc-build-dotgnucash-path "saltant-invoice.scm"))
> > 
> While that is a good workaround it tapers over the actual bug.
>  
> The format used by John W. used to work until gnucash 2.6.3 and stopped working on 2.6.4. I can even reproduce this on Fedora so it's not OS X specific.
>  
> I have traced it back to my patch for
> Bug 711567 - Cannot save a custom report if a path contain diacritic chars
>  
> And looking back it's relatively easy to explain: until 2.6.3 it was guile that loaded the config file and ran the commands in it. In this case it is a bunch of load commands with relative path names. Guile will resolve these path names relative to the config file.
>  
> In gnucash 2.6.4 though the file is loaded by the c code and the commands in it are passed as a plain string to guile. In this case guile no longer knows about the location of the original config file and can no longer resolve the relative path names correctly.
>  
> I have some mixed feelings on how to deal with this.
>  
> The proper solution is to make guile handle pathnames with diacritical characters correctly on Windows. I've spent about a week trying to do so with the help of both the mingw and the guile community and failed. I don't feel like spending even more time trying to work around broken charset support in an external library on Windows.
>  
> On the other hand Derek's workaround is fairly easy. So I'm tempted to just update the wiki page that explains how to load a custom report and continue with more pressing matters.
>  
> What do you think ?

One possible solution is to get Guile out of the file-opening loop. Having a configuration file that’s directly executed by Guile is a rather glaring security hole; it would be much better to make it an ini-style file and do everything in C/C++ up to passing the contents of the files to a Guile function that registers them as add-on reports. That’s not really a suitable change for the maint branch, but we should consider it for 2.8.

Otherwise I’m completely comfortable with the workaround.

Regards,
John Ralls