Re: OLL-core and Win10 [was Re: edition-editor usage]

[Urs Liska]

Am 08.01.2018 um 14:50 schrieb David Kastrup:
> Urs Liska <address@hidden> 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