lilypond-devel
[Top][All Lists]

## Re: Problem with 2.13.30?

 From: Reinhold Kainhofer Subject: Re: Problem with 2.13.30? Date: Sun, 29 Aug 2010 21:33:55 +0200 User-agent: KMail/1.13.5 (Linux/2.6.32-24-generic; KDE/4.5.0; i686; ; )

```Am Donnerstag, 26. August 2010, um 11:04:15 schrieb Trevor Daniels:
> "Phil Holmes" <address@hidden> wrote in message
> > Line 4 in the snippet map is
> > "C:\Users\Trevor\LilyPond-git\Documentation\music-glossary.tely")
[...]
> Your explanation is pretty close.  The snippet map in
> Windows should contain forward slashes rather than
> escaped ones.

Thanks, Trevor, for you bisecting... The culprit is actually not the
refactoring, but a bug fix I did before the refactoring (commit

The problem I fixed with it was quite ugly (and I wonder why noone ever ran
into it and complained): If your want to run lilypond-book on a file with
*.tex, *.html or *.texi extension, you need to use the --output option,
because otherwise the input file would be named the same and the input file
would be overwritten.

Unfortunately, in this particular case (where the file name of the input and
the output file was the same), the check for input==output file was terribly
broken. Try it out by creating a file test.tex and run
lilypond-book --output=out test.tex
on it. The first time, it will work and create out/test.tex, but the second
time it will complain that the output file is the same as the input file
(which it is not!) and refuse to work on the file.

In that case, the input filename is simply test.tex, and the output filename
is C:/path/to/out/test.tex. The problem was that sooner or later the lilypond-
book script changed the current directory to the output directory (after
reading in the input file's contents). As a consequence the input filename
"test.tex" was now taken relative to the output filename, and then the input
and output filenames were really identical.

As a solution, I changed the input filename from a relative path (which causes
problems as soon as the current working dir is changed in a script) to an
absolute path by calling os.path.abspath (...).
Unfortunately, os.path.abspath (...) on Windows has the side-effect of
changing all / to \. See http://docs.python.org/library/os.path.html

I don't really see any other way to turn the input path to an absolute path
than calling os.path.abspath, in particular, since the input path can already
be an absolute path...

Cheers,
Reinhold

I don't remember how to reproduce the problem, but the issue was that with
some files containing include files (involving subdirectories somehow), some
output pathes were taken relative to the current working directory.
Now, the lilypond-book at some point changed the working directory to the
output directory, so those paths were suddenly taken relative to the output
directory rather than the input directory.

As a solution, I

>
> Here's what happens now with various releases.
>
> 2.13.23 and earlier
>
> Snippet map contains forward slashes, so no problem
>
> 2.13.24 - 2.13.29
>
> lilypondbook fails with pipe problem now, see
> http://lists.gnu.org/archive/html/bug-lilypond/2010-07/msg00060.html
> so no snippet map is produced.  (This seems to depend
> on past history or my system as 2.13.26 on one occasion
> got further and failed with the snippet map containing
> backslashes, and IIRC Eluze reported the msvcrt problem
> in this release.)
>
> 2.13.30
>
> lilypondbook fails with msvcrt problem, fixed in 2.13.31
>
> 2.13.31
>
> Snippet map contains backward slashes, so fails
>
> Trevor
>
>
>
> _______________________________________________
> lilypond-devel mailing list
> http://lists.gnu.org/mailman/listinfo/lilypond-devel

--
------------------------------------------------------------------