Re: lynx-dev Improper ~/ expansion in file://

[Klaus Weide]

On Thu, 19 Nov 1998, Ryan Hung wrote:

> I have just rejoined the list after a long absence, so I am unsure whether
> this issue has been addressed (a brief search on the archives yielded
> nothing).  Basically, I have observed that in Lynx >2.8.1 (up to
> 2.8.2dev.4), file://localhost/~ gets expanded as, e.g.:
> file://localhost//home/username.  This means that %p for DIRED_MENU
> commands is incorrect, breaking operations like changing file permissions.
> I located what seems to be the relevant section in LYGetFile.c (line 587
> in 2.8.2dev.4), but don't understand it well enough to determine whether
> this is buggy code.

I see the same in 2.8.1rel.2.

There are actually at least two problems.  Only in combination do
they prevent changing file permissions from working:

 1) the additional slash in the URL
 2) The functions in LYLocal.c do the wrong thing with the strings
    they get.  In this case permit_location() gets passed
    "//home/username", which it passed to HTfullURL_toFile, which
    is a macro to a call of HTnameOfFile_WWW() [in HTFile.c].
    HTfullURL_toFile() is inappropriate here.  It treats the
    string as a relative URL (so that "home" is seen as the host
    part of an URL) which it isn't. It also tries to URL-unescape
    the string which is also inappropriate: See what happens
    for a file named "%backup%~".

    Earlier versions of LYLocal.c didn't do all this.  For example
    permit_location() worked for filepaths with duplicate slashes
    (which are just ignored under Unix) and for filenames with "%".

I suggest reverting LYLocal.c back to a previous version that is
better behaved, or changing the new macros and functions there to
something appropriate.

Note that permit_location() should always get a filename or file
path as its srcpath argument, not a URL.  The code

         if (strncmp(srcpath, "file://localhost", 16) == 0)
            srcpath += 16;
 
which appears in previous versions may have been misleading because
if makes one think otherwise.  But AFAIK that test would normally
never apply.  I just left it in when I went through LYLocal.c a
long time ago.  I thought someone who had put it there a still longer
time ago might have had a still valid reason for it.  But it didn't
seem to get used at least with the usual DIRED_MENU rules.

(The same may apply to many or most functions in LYLocal.c.)

    Klaus