Am 08.01.2018 um 14:50 schrieb David Kastrup:
Urs Liska <li...@openlilylib.org> writes:
Hi Trevor
Am 27.12.2017 um 14:33 schrieb Urs Liska:
Done; here's the log output:
Starting lilypond-windows.exe 2.19.80 [Untitled]...
Processing
`C:/Users/tdani/AppData/Local/Temp/frescobaldi-u9vnw1qc/tmp4_jxjpvb/document.ly'
Parsing...
location: #<location
C:/Users/tdani/openlilylib/oll-core/package.ily:57:2>
initial path: C:/Users/tdani/openlilylib/oll-core/package.ily
this file: (C:/Users/tdani/openlilylib/oll-core/package.ily)
OK, here we are. This should be a list with the path elements, but
it has the whole path in*one* list element. And throws an error when
trying to access the second-to-last element.
With this information I can debug the function.
I've now had the chance to look into this issue, and it's clear what
happens. I could easily fix that *for you*, but I'm not sure about the
*proper* fix.
The path handling functions in oll-core work in an OS dependent way
and define an OS path separator of "\" (Windows) or "/"
(otherwise). But in your log "/" is used on Windows as well.
I know that by now Windows can handle both forward and backward
slashed.
That's news to me. Aren't you confusing this with the C library
commonly used on Windows? And with particular shells?
And particular runtimes? Like Cygwin/MinGW ?
Probably we're talking about different things. What I mean is that you
can type both of these into a standard cmd.exe on Windows (7):
cd c:\Windows
cd c:/Windows
But actually that's not what's interesting to me. My question is what to
expect on different systems when parsing the output of (*location*).
Best
Urs
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
