Re: LYNX-DEV lynx-386 filename problem

[Klaus Weide]

On Sun, 21 Sep 1997, Doug Kaufman wrote:

> On Sun, 21 Sep 1997, Klaus Weide wrote:
> 
> > 1. Could you change the patch to HTInit.c so that it doesn't duplicate
> >    the whole function body?  It would be much easier to see what your
> >    changes are if you could #ifdef only the relevant lines.
> 
> I tried to do that originally. The default suffix for temporary files
> is the last one listed for each mime type. When I did individual ifdef
> lines, it didn't seem to change the default, so I tried it with the
> whole function, which did change the default suffix.
> 
> Some of the changes were simply rearranging the lines, so that a valid 3
> character suffix was listed last.  I wasn't sure how to do this without
> changing the default order for other OS's.

Try changing HTFileSuffix() in HTFile.c so that for DOS is will return
a suffix of length 3 in preference to a longer one, independent of order.
That should eliminate the need for the reordering-only changes.
Something like this:

PUBLIC CONST char * HTFileSuffix ARGS1(
        HTAtom*,        rep)
{
    HTSuffix * suff;
#ifdef FNAMES_8_3
    HTSuffix * first_found = NULL;
#endif
    int n;
    int i;

#define NO_INIT  /* don't init anymore since I do it in Lynx at startup */
#ifndef NO_INIT
    if (!HTSuffixes)
        HTFileInit();
#endif /* !NO_INIT */
    n = HTList_count(HTSuffixes);
    for (i = 0; i < n; i++) {
        suff = (HTSuffix *)HTList_objectAt(HTSuffixes, i);
        if (suff->rep == rep) {
#ifdef FNAMES_8_3
            if (suff->suffix && (strlen(suff->suffix) <= 4)) {
                /*
                 *  If length of suffix (including dot) is 4 or smaller,
                 *  return this one even if we found a longer one
                 *  earlier - kw
                 */
                return suff->suffix;
            } else if (!first_found) {
                first_found = suff;             /* remember this one */
            }
#else
            return suff->suffix;                /* OK -- found */
#endif
        }
    }
#ifdef FNAMES_8_3
    if (first_found)
        return first_found->suffix;
    else
#endif
    return "";          /* Dunno */
}

 
> > 2. For the HTInit.c changes, please consider to not change HTFileInit
> >    at all, but instead put necessary changes in a mime.typ(es) file.
> >    That should override or add to whatever is in HTInit.c, be more
> >    configurable, and much more convenient for testing (no recompilation
> >    needed for changes).  Also some of the types in HTFileInit are really
> >    outdated, and the MIME types with spaces in them are questionable
> >    (they are only used to get a "nicer" display e.g. in FTP listings),
> >    you shouldn't add more of those.  You are effectively introducing
> >    some new "conventions" (
> >      HTSetSuffix(".bcZ",  "application/x-Comp. BAK File",...)  ??
> >      HTSetSuffix(".gta",  "application/x-gtar",...)            ??? )
> >    which AFAIK are not used by anyone.
> 
> DOS can only have a three-character suffix. Since the default suffix is
> chosen from the list in HTInit.c, there should be a 3 character default
> for each type if the 8+3 constraints are to be kept. I made some of
> these dummy suffixes, as noted above, which are not used in the real
> world.

Yes, I know about the 8+3 constraint of DOS; what I don't know so well is
where it actually plays a role and where it can just be ignored.  

Those Suffix rules are used in four ways, as far as I understand:

1) to map a suffix to one of 7bit | 8bit | binary
   (only relevant for FTP and, for VMS, for files passed to a VIEWER)

2) to map a suffix to a string displayed in FTP listings
   (in particular the "gfancy" ones with spaces and/or capital letters,
   which are not much use otherwise)

3) to map a suffix to a content-type, so we know what to do with a file
   (HTFTP.c, HTFile.c)

4) to map a content-type to a suffix, for creating temp files
   (HTFWriter.c; text/html, text/plain, and application/octet-stream
   handled specially)

They are NOT used for making suggested filenames for saving a document.

To simplify things, for now (and for DOS) let's forget about 1) and 2).
There are roughly two kinds of problems which can occur:

(a) miscommunication between Lynx and an external problem invoked by
    Lynx.  Aside from possible problems with invoking gunzip,  these
    problems would involve passing a filename which is "too long" to
    a VIEWER or PRINTER command (but most commands probably just
    ignore the superfluous characters); or just a name with the "wrong"
    suffix.

(b) miscommunication between one part of Lynx and another.  That is where
    one function writes a file with a specific suffix (probably mapped
    from a content-type) and then another function tries to open that file
    and derive a content-type/content-encoding from its suffix - which
    may not be the same as the original one...  but I think this can
    only happen when Lynx tries to decompress a file, and then only 
    sometimes, and therefore is rather obscure. 

> A mime.types file (or DOS equivalent) would work, but would be
> an extra configuration step that might discourage novice DOS users
> unfamiliar with unix-type conventions.

They could also go in lynx.cfg as SUFFIX rules btw. but that alone
wouldn't help here since HTFileInit is called after reading lynx.cfg.
It may still be useful to put some types there in a DOS/Windows specific
distribution.
 
> 
> >    Maybe the functions HTSetSuffix() and HTFileSuffix() should be modified
> >    instead (for 8+3 systems).
> 
> This sounds like a good idea.

See above for a start.  Also tempname() should be changes, and all places
where ".html" files may be created should probably change that to ".htm"
for DOS.  #define HTML_SUFFIX ".htm" for DOS, ".html" for everything else,
and then use that in the relevant places including tempname().


> > 5. consider using a more specific symbol instead of __DJGPP__ (something
> >    like DOS_8_3_NAMES...), that would make it much easier to track those
> >    changes.
> 
> "__DJGPP__" is the recommended symbol for indicating compilation with
> DJGPP and is automatically generated by the compiler (recommended by
> D. J. Delorie, that is). I don't know enough about the other operating
> systems to know if changes for DJGPP belong in other systems that use
> the DOSPATH symbol or not.

DOSPATH is overloaded AFAIK (I haven't checked whether that's still the
case), so I wouldn't use that - it should probably say something about
the format of a full path up to the last component, not whether that
component should be converted to 8+3 or not.

But I don't think this problem is specific to DJGPP, at least in
principle.  Although currently it seems the only system where 8+3
is a problem (if it really is :)) happens to be also the only system
where the compiler is DJGPP, it may not always stay like that.
Or someone may want to enable this for a MS Windows system (LFN not
working? A hypothetical Windows 3.1 port? ...).  How about for now

#ifdef __DJGPP__
#define FNAMES_8_3 1
#endif

in the relevant files.  (Or just -Define in the makefile.)

[...]

> Gary Turner suggested possible use of the DJGPP function _truename,
> which truncates to 8+3 as part of its function.  I am not sure how to
> apply this, however.

What else does it do?  A function to convert a given M+N filename into
a DOS-correct 8+3 filename could be easily written if we need it.  But we
still have to figure out where it should be applied (and whether it is
necessary at all).

> > A starting point for this would be that users have to learn to make usable
> > and detailed problem reports to the list (or to whover wants to support
> > the code for DOS).
> 
> Unfortunately, most users with problems have never made a problem report
> and don't know what information is needed for others to help them.

And there seem to be more severe ones than this.  Which are too specific
to DOS/DJGPP  for me to know anything.

   Klaus


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