tech-userlevel archive

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

Re: Encoding non-alphanumeric characters in manpage filenames

      page "." section-extension ( "." other-extension )*

Such a filename can be correctly split at dots without knowing what
manual sections, compression tools, and other tools are in existence.

You still haven't explained why this is a valuable property, in
particular why it's more valuable than preserving existing filenames
for existing manpages (eg, resolv.conf(5)).

It's not more valuable than backward compatibility. We should support the existing filenames too.

As far as I can see, manpage filename encoding does not need to be a
two-way process as far as automated tools are concerned.  Manpage names
get converted into filenames, but I see no reason for anything below
the human layer to go the other way.
It's a good design principle for data formats to stand alone and be self-describing (within reason) without relying on particular programs and their use cases. To the extent that the format is successful, the set of programs and uses cases will expand in unforeseen ways. Gzip compression with a ".gz" extension is a feature that was added relatively late in the life of manpages; subsections (3lua instead of just 3) are another. There will probably be others.

In the present case, it's prudent to establish a clear rule by which the filenames in man/cat directories can be taken apart to find the page, section, and other suffixes. (This precludes using ".7z" compression for manual pages, as Thierry pointed out, or else all tools which interpret manpage filenames will have to account for ".7z" as a special case.) If this rule is similar or identical to other such rules (e.g. standard filename extensions, URL encoding), so much the better.

Home | Main Index | Thread Index | Old Index