Re: Encoding non-alphanumeric characters in manpage filenames

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> The suffix is hopefully restricted to [0-9a-z.] in all cases, and
> hence doesn't need to be escaped.

"hopefully" is not a good basis for designing something like this.  Or
at least that's my opinion.

Since you've said this is for man(1)'s purposes, surely you can find
out what suffixes are possible by examining man and/or its
configuration?  (If not, man needs better documentation.)

> Escaping "." in the stem part is good practice when the name of a
> manpage contains a dot.  The manpage for "java.lang.System" in
> section "3java" should become something like
> "java%2Elang%2ESystem.3java".  Then it's clear what's the suffix and
> what's not.

Why?  Why is it valuable to "[be] clear what's the suffix and what's
not"?  I thought man(1) looked for manpages by constructing a filename
by appending one (or a few) of a relatively small set of strings (.1,
.2, .3, .1.gz, .3java, etc) and seeing which one(s) it can find.  I
don't see anything in there that makes it important, or even useful, to
be able to do the reverse, to look at, say, java.lang.System.3java and
mechanically determine that the .3java part is an added suffix and no
part of java.lang.System is.

That's not to say that there's no value in it.  Just that I'm not
seeing it yet.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B