Re: forcing html rendering for files without extensions

Mouse wrote in
 <[email protected]>:
 |> I realized I wanted it to interpret files without extensions as HTML
 |> [...]
 |
 |Well...keying things off filename extensions is a useful heuristic.
 |But there is a problem with it, more or a problem in the abstract than
 |a pragmatic problem: what is an extension?

To note that IANA has a media type registry, and that file
extensions are (most often -- i had to find exceptions) bundled
with media types within it.

 |In most Unix variants (I'd almost say "all", as to my mind this is one
 |of the distinguishing charateristics of the Unix family), dots are not
 |special in file names except to userland programs, and only some of
 |those.  If a filename contains a dot, whether the part after it is an
 |"extension" is not well-defined; it depends on human-layer things:
 |
 |saved.html
 | Probably conceptually the name "saved" with "html" extension,
 | presumably tagging the content as HTML.
 |
 |one.two.three
 | Does this have an extension?  If so, is it "three" or
 | "two.three"?   Since neither one has any common semantics as an
 | extension, this probably is conceptually the name
 | "one.two.three" with no extension tag - but that depends on
 | human-layer knowledge.
 |
 |log.2026-08-04.12:14:55
 | Almost certainly a name without any extension tag.
 |
 |Context is also important.  If we have a directory containing files
 |named

Yes.  Btw already -alpha released is a change in the MUA
i maintain, the NEWS entry reads

  + MIME classification learned about chains like .tar.gz.
    New ?o [only-handler] `mimetype' marker, a good thing.
    Both: (Olaf Hering)
    Also new ?s [send-text] marker.

      Because MIME media type handlers, like those defined in "The
      Mailcap files", match media types, non-standardized fictional
      types like "x-tar-gz" are used in the wild as MIME environments
      become configured.

      That is, IANA MIME registry standards do not know about "extension
      chains": "tar.gz" is thus a gzip(1) compressed file, and the sane
      solution of recursively unpacking until no more MIME media type
      unpacking is possible is not available.

      Therefore introduce this type-marker, which says that the given
      MIME media type shall only be matched when looking for handlers,
      but not when classifying content to create messages.

    Some are built-in by default, see
      $ MUA -:/ -Xmimet -Xx | grep only-hand

So the idea was "recursively unpacking known extensions chains
until no more unpacking is possible".

 | 'qZUH]Qc1wtc
 | zi)dvndrx~f,
 | k)|BAr.(I@a"
 | a\i;Dqj|")4g
 | QWL0;)7s[Vee
 | 9=%^3Pw-,>f2
 | \Zlt5K|kYQo)
 | #"8PrHA>3H2{
 | )(`VY2murLC3
 | K45aG_Mfdv.c
 | phg}7]~]}$O>
 | $xQkguC\}_lq
 | +r6U`09V;MFd
 | r@`aHPYrt2]f
 |
 |then, even in isolation, the third filename is extremely unlikely to be
 |a name-plus-extension.  In isolation, the tenth one might be C source
 |code (the rest of the name makes that seem somewhat unlikely, but I've
 |seen similarly cryptic names in real programs).  In context, it is all
 |but certain to be pure coincidence.
 |
 |Similarly, if we have
 |
 | app.c
 | bkgnd.c
 | externs.h
 | log.c
 | lzw.c
 | norm.c
 | saves.c
 |
 |in one directory and
 |
 | log.a
 | log.b
 | log.c
 | log.d
 | log.e
 | log.f
 | log.g
 |
 |in another, then the log.c file is probably C source in the first case
 |and probably not in the second, despite the identical names.
 |
 |The hard part, of course, is telling the difference mechanically;
 |that's why so many things use such heuristics.

Also a very correct observation.  Yet, in practice, i find it
constructed really, because i would assume the latter example
being in a very dedicated environment that would not be mixed up.

Having said that, the file(1) utility and the file "magic"
database (of Zoulas of NetBSD, the latter of which you have
a certain closeness), as well as Apache Tika [1], have a content
inspection framework which performs in-depth analysis.
I used [1] as a source of file extensions, but i always felt
total horror thinking about doing in-depth inspection for MIME aka
media type detection.  It felt and still feels to be total
overkill.  I mean(t), on Unix, yes, i also at times do the above
(though more often .1 .2 .3 etc, .. which interferes Unix manuals
a.k.a. text/troff), but on for example Windows people surely do
not even *know* that this is possible, but take the file extension
and program bundle for granted.

  [1] https://github.com/apache/tika/blob/main/tika-core/src/main/resources/org/apache/tika/mime/tika-mimetypes.xml

I would love to get this "extension-chain" notion into the wild.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)