[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.
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.
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.
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.
Main Index |
Thread Index |