Custom reports do not load after upgrade to 2.6.4 on OSX

[Geert Janssens]

On Tuesday 21 October 2014 07:01:05 John Ralls wrote:
> > 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.
> 
I understand your reasoning. However a custom report in itself is essentially unrestricted 
scheme code as well. So how is loading such a file via C/C++ any less of a glaring security 
hole than having it done in guile ?

> Otherwise I’m completely comfortable with the workaround.
> 
Ok.

Geert