lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV lynx-386 filename problem


From: Doug Kaufman
Subject: Re: LYNX-DEV lynx-386 filename problem
Date: Sun, 21 Sep 1997 22:52:42 -0700 (PDT)

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


>    Maybe the functions HTSetSuffix() and HTFileSuffix() should be modified
>    instead (for 8+3 systems).

This sounds like a good idea.
 
> 3. Your changes in HTCompressed() are at odds with HTFileInit().  You
>    create suffixes ".hZ", ".hgz", ".tZ", ".tgz", ".bZ", ".bgz" instead of
>    ".html.Z", ".html.gz", ".txt.Z", ".txt.gz", ".bin.Z", ".bin.gz" (and
>    no change for compressed files of different recognized or
>    unrecognized content-types).  HTLoadFile() will not recognize those
>    suffixes, or recognize them as something else (esp. ".tgz").
> 
>    These are changes that only are effective in situations that you
>    probably haven't tested.  You'd have to test with compressed files
>    from HTTP, FTP and local file URLs, and it should also make a
>    difference whether you have compiled with USE_ZLIB or not (I predict
>    more problems without it).  In other words it gets rather messy,
>    but I doubt that this change makes things work better in general for
>    DOS users.

DOS filenames can NEVER have 2 "." in them.  Suffixes such as .txt.gz,
.bin.gz, .htm.Z, etc. can not be written to the filesystem.  The DOS
version of gzip is smart about this and makes acceptable suffixes
automatically.  Thus when "mime.typ" is gzipped, it comes out as
"mime.tyz". I wasn't sure how this section should be handled, but
filenames with 2 dots can't exist in DOS. I think that a DJGPP program
can work with them internally, as long as they don't actually have to be
written to the file system.
 
> 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.
 
> 6. The (first) change in LYPrint.c where your check for ".htm" won't
>    actually work, you'll also have to adapt the ' len -= 5; '.

Thanks.  I'll fix that.
 
> 7. Some other functions that probably need changes for this to work
>    somewhat:
>    tempname() in LYUtils.c, and HTCheckFnameForCompression() in
>    GridText.c.  Probably change_sug_filename() in LYUtils.c.
>    There may be others.
> 
> 
> How much of a problem *is* there actually, with the current code?  And how
> much of it occurs only with programs which have the behavior described
> by Gary Turner (above), .i.e. not ignoring suffix characters after the
> third character?  In which situations, and with which file types, do
> the problems occur?

I am not sure how big a problem this is.  I don't know how many people
are actually trying lynx_386 for DOS. I suspect that DOS programs that
are unix ports aren't a problem.  There may be a number of programs
written with no consideration of compatability with other operating
systems or conventions.
 
> I think (IMHO) concrete problems should be identified, and then we can try
> to solve them, rather than just trying to make changes which look right
> for DOS on the surface (but it's not clear whether they are (a) necessary
> (b) sufficient (c) create other problems).

I agree - especially about not creating other problems.
 
> For example, *if* there is only a problem with calling external programs
> (VIEWER, PRINTER, ??), it *may* be better to just shorten the suffix
> (AND filename proper!) where this actually occurs; or even just adopt the
> helper apps to do that.  If there is a more general problem, then maybe
> DOS needs a wrapper function around fopen() (which would call fopen()
> after munging the filename) [only for opening with "w"?], and/or some
> changes to other functions (see 2. and 7. above).  But AFAIK the problems
> haven't been properly identified or discussed.

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

Thanks for the constructive thoughts about this.  I'll keep trying to
look at the code, but I am not a C programmer, so I don't always have a
reasonable idea about how to fix a problem.
                                Doug

__
Doug Kaufman
Internet: address@hidden (preferred)
          address@hidden

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

reply via email to

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