[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: |
Mon, 25 Jan 2016 10:07:46 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
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.
> 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. 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?
--
David Kastrup