[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev Improper ~/ expansion in file://
From: |
pg |
Subject: |
Re: lynx-dev Improper ~/ expansion in file:// |
Date: |
Sun, 22 Nov 1998 16:54:05 -0700 (MST) |
In a recent note, Klaus Weide said:
> Date: Sun, 22 Nov 1998 16:33:45 -0600 (CST)
>
> A good question. I don't know the real answer, but "\\" in Windows (which
> probably would be translated into "//") has a specific meaning, and I seem
> to recall that POSIX or some similar spec for Unix says something like
> "a // at the beginning may have system-defined meaning". (Can anyone
> confirm?)
>
(I don't have the document handy; this is from memory.) POSIX notes
that there is a convention of accessing remote filesystems:
//<hostname>/<pathname>
POSIX tolerates this, but "strongly recommends" that developers
of new systems not implement this convention. On the other side,
POSIX recommends that application developers not build paths
by grafting a branch onto a stem:
$STEM'/'$BRANCH
because if STEM is '/', this results in a path beginning with the
treacherous two slashes. Instead, POSIX recommends:
$STEM'//'$BRANCH
If STEM is '/', this results in '///'$BRANCH, which begins with
three slashes, and only exactly two leading slashes may introduce
the remote filesystem construct.
A colleague points out that this is likely the genesis of the
URL syntax:
<scheme>'://'<hostname>'/'path
> Maybe it is only at the beginning of a pathname that "//" should be
Elsewhere, POSIX doesn't allow it to matter.
> preserved, but a function like LYTrimRelFromAbsPath() may get called
> in many places and doesn't generally know if the string is a full
> path. So the safest thing may be to leave it alone once a "//" somehow
> got into a path. That is what lynx does, for the most part. If a user
> enters a path like that, he gets what he deserves (or maybe has a good
> reason).
>
> A complication is that URL paths and (at least Unux) filesystem paths
> act differently w.r.t. "". For files, a ".." steps back over multiple
> slashes, but if I read the URL syntax correctly a ".." should step "in
> between" the two slashes, there is a path segment between them that just
Particularly, RFC 1808 details the semantic difference of ending a
URL path with a '/', something that makes no difference in POSIX
paths. Roughly, if the URL is given as:
scheme://host/foo/bar/
and the relative URL is X, the current directory is taken to be the
entire URL, and the constructed URL is:
scheme://host/foo/bar/X
whereas if the base URL had been simply
scheme://host/foo/bar
the constructed URL is:
scheme://host/foo/X
-- gil