Re: Behaviour of is-absolute?

[Urs Liska]

Am 25.01.2016 um 10:07 schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
>
>> Hi all,
>>
>> now that is-absolute? is not broken anymore (see #4746 and #4747) I'd
>> like to raise the question of its *behaviour* - which seems somewhat
>> inconsistent to me.
>>
>> Currently this function behaves differently on Windows and elsewhere,
>> and I think this shouldn't be the case.
>>
>> is-absolute? expects a string representing a file path.
>> It returns true if either
>>
>> it starts with a slash
>> or
>> if on Windows it starts with a drive letter.
>>
>> So
>>
>> (is-absolute? "/some/path")
>> always returns #t
>>
>> but
>> (is-absolute? "C:\some\path")
> You presumably mean "C:\\some\\path" here.

Yes, sorry.

>
>> or
>> (is-absolute? "C:/some/path")
>>
>> returns #t on Windows but #f on Unix.
>>
>> I think such a function/predicate should behave consistently,
> It does.  It follows the conventions of the system.
>
>> and I can see two ways of doing so. Either it should look for both
>> path syntaxes so all three of the above examples return #t on all
>> OSes. Or it should exclusively look for the current OSes syntax, so
>> the first example returns #t *only* on Unix while the other return #t
>> *only* on Windows.
>>
>> Thoughts?
> Pretty much every C library on Windows disagrees and will accept forward
> slashes as well as backward slashes.  

Of course, this is what I fixed with #4746 (*now* LilyPond also accepts
forward slashes).

> And "C:\\some\\path" is a valid
> relative path (resolving to a file in the current directory with a
> rather peculiar name) on Unix.  I've used this for test purposes
> already.
>
> What actual problem are you trying to address here?

LilyPond will consider "C:\\some\\path" an absolute path when compiled
under Windows, but not when compiled under Linux/Mac. So this means: it
works according to the current OS.

But LilyPond will consider "/some/path" an absolute path regardless of
the OS.

I think LilyPond should either *always* act corresponding to the OS (so
"/some/path" will be considered absolute only on *NIX) or it should
always return true to *all* possible ways of specifying an absolute path.

Urs