[Top][All Lists]

[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:


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:


because if STEM is '/', this results in a path beginning with the
treacherous two slashes.  Instead, POSIX recommends:


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:


> 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:


and the relative URL is X, the current directory is taken to be the
entire URL, and the constructed URL is:


whereas if the base URL had been simply


the constructed URL is:


-- gil

reply via email to

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