Re: LYNX-DEV /foo/.. ?

[Klaus Weide]

On Mon, 4 Nov 1996, Wayne Buttles wrote:
> On Mon, 4 Nov 1996, Klaus Weide wrote:
> > On Mon, 4 Nov 1996, Wayne Buttles wrote:
> > > Klaus Weide (address@hidden) wrote:
> > > 
> > > > I don't know what happens with such paths on DOS, I think multiple
> > > > backslashes in arbitrary places are illegal there.
> > > 
> > > Is there a rule here?  I couldn't find rules for file:// from a quick
> > > search.  
> > 
> > What kind of rule do you mean?   RFC 1738 talks about file: URLs, and
> > RFC 1808 talks about resolution of relative URLs (in general).
> > 
> > >    My current DOS URL bastardization accepts the following (and a
> > > bunch more variations):

Well, as I already tried to say: I suggest accepting them from the user, 
but immedately converting them to something that fits into the general
URL framework.  That should save trouble down the road. 

> > Let me try to apply the RFCs to your examples:
> > 
> > > file:////lynx/bookmark.htm
> > 
> > Now here we have one slash too many, illegal according to the syntax
> > of RFC 1808 (but not RFC 1738).  That extra slash doesn't seem to
> > fulfil any useful purpose.  (file:///lynx/bookmark.htm should always
> > refer to the same file IMHO, i.e. the path in a fully specified URL
> > should always be taken as an absolute path.)
> > 
> 
> It actually does fulfill a purpose, if you squint your eyes real tight and
> look at it sideways...  ;-)  It replaced `c:/' i.e.: 
> 
> file:////lynx/bookmark.htm
>        ^^
>        ^^\null dos drive
>        ^
>         \ null localhost

I don't know of any such thing as a null DOS drive - unless you mean NUL:.

More seriously, why do you need such a thing, and why can't 
 file:///lynx/bookmark.htm
fulfill that purpose??

Absolute URLs should be absolute period.  I case of a file: URL, well
it cannot have a unique meaning in a world(-wide-web)-wide context, but
it should have a unique and absolute meaning in the context of the 
local machine.  In case the "null drive" is supposed to mean "whatever
happens to be the curent DOS drive", I think that is a bad idea -
you would be trying to fit a relative path into an absolute URL.

Now, file:///lynx/bookmark.htm doesn't specify a drive explicitly,
so some assumption has to be made (always use C: ?).  But at least it
doesn't reserve a syntax-violating slash for a bogus purpose...
 

> My first attempt ended up in a direct 1 to 1 translation of the slashes
> until the path portion is hit.  I don't know yet what would happen if I
> take it out.  It might break access of temp files, options, key map,
> info page, history...  all which are working now. 
> 
> > 
> > > file:///./\/\/\////\\\bookmark.htm
> > 
> > I am not even sure what that monstrosity is supposed to mean.
> > I just note that an absolute path starting with "." is somewhat, hmm,
> > ill-defined.  Is that relative to the root directory?  
> 
> . means this directory just like it does directly on a unix filesystem:
> 
> ./lynx http://lynx.browser.org (run my own darn copy)

But in that case the reference point is clearly defined: the Current 
Working Directory, as stored (normally) in a shell's PWD variable etc.
You have just avoided the question: what is "this" directory?
 
> The rest was just crap.  It just boils down to ./bookmark.htm

Well, it doesn't.  At least if we are talking about URL syntax, not
OS filesystem syntax (and then it should be .\BOOKMARK.HTM for DOS :) )

Of course ./bookmark.htm is a valid relative URL.  But when it is 
interpreted as a relative URL, that has to be resolved against an
(implicit or explicit) base URL.  The dot then has quite a different
meaning from the Current-Working-Directory dot in unix and DOS, and
it would be better to regard it as pure coincidence that the same char
is used in both cases.

Anyway, the dot in the middle of an absolute URL that you propose to use
cannot possibly be the URL syntax dot.  Because that one is volatile 
and will (or should) disappear the first time such an "URL" is
subjected to HTSimplify & friends.

> How do you access a file on the current volume in VMS with lynx without
> putting the volume in the path?
> 
> file://localhost//lynx/bookmark.htm 
> 
> or
> 
> file://localhost/lynx/bookmark.htm 
>
> ?

Think what happens if that first URL is subjected to 
HTParse(<url>, PARSE_PATH + PARSE_PUNCTUATION) or similar.
You'll get something that looks like a partial/relative URL
starting with the host part (where "lynx" is the host).
A few more iterations through the URL parsing machinery, and
you get total garbage.  I think it is impossible to adequately
foresee all possible points in the code where a partial URL might
be parsed in this or that way - it certainly is for me.  
So the best way to avoid strange surprises (let's throw in a IMHO here)
would be to make sure URL strings follow the rules for URL syntax,
whether you like them or not, whether they seem to make sense or not..

But I think i am repeating myself..

  Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;