lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Behaviour of is-absolute?


From: Urs Liska
Subject: Re: Behaviour of is-absolute?
Date: Tue, 26 Jan 2016 16:08:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1


Am 25.01.2016 um 11:55 schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
>
>> Am 25.01.2016 um 10:07 schrieb David Kastrup:
>>
>>> 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.
> Why?  I repeat: What actual problem are you trying to address here?
>
> With "actual" meaning something affecting a user in a negative and/or
> unexpected way.  As far as I remember, / cannot ever be in the name part
> of a file name with either Unix or Windows.  According to Microsoft:
>
>     Which characters can't be used in a file name?
>
>     You can't use any of the following characters in a file name: \ / ?
>     : * " > < |
>
> In Unix, there are only two forbidden characters, / and NUL.  But at any
> rate, there does not seem to be _any_ potential for a problem/confusion
> here.
>
> What actual problem are you trying to address here?

that someone gets hold of a path like "C:\\some\\path" and expects
is-absolute? to evaluate to #t with it - which it won't do when compiled
on Linux.

But as you insist that strongly I start to think that this case
shouldn't really happen, as any paths any LilyPond functions might
return are either according to the OS or "slashified", i.e. Unix-like.

So I think we can leave it at that - if a user should actually run into
this it can be easily fixed.
This is why I wanted this discussion separately from the previous patches.

Urs



reply via email to

[Prev in Thread] Current Thread [Next in Thread]