[Top][All Lists]

[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\\" 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

reply via email to

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