[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Behaviour of is-absolute?
From: |
David Kastrup |
Subject: |
Re: Behaviour of is-absolute? |
Date: |
Tue, 26 Jan 2016 16:27:36 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
Urs Liska <address@hidden> writes:
> 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?
What does "someone gets hold of a path" even mean? That sounds like
catching a cold.
> to evaluate to #t with it - which it won't do when compiled on Linux.
When would that _ever_ occur? What _actual_ problem are you trying to
address here?
> 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.
Can you point out _any_ actual imaginable problem case? Involving
computers and LilyPond rather than people "getting a hold of a path"?
> So I think we can leave it at that - if a user should actually run
> into this it can be easily fixed.
Users don't execute is-absolute?. Programs do. If someone writes a
file "C:\\some\\path.ly" on GNU/Linux because that's what the original
author of some LilyPond document set the output name to for some reason,
the resulting file will be stored in a relative path. If you want to
access it absolutely, you'll have to prepend the respective local
directory path.
I don't see that letting a GNU/Linux installation pretend that it is
Windows will magically lead to better results. Quite the opposite.
--
David Kastrup