Bugzilla Bug 222439

There are some packages that build manpages suffixed with the language codes
like foo.1, foo.es.1 foo.fr.1.

I would like "doman" to handle this situation as I think this scheme is quite
reasonable and not so uncommon, specially since debian's debhelper has support
for it. An currently there is no pleasant way to deal with this situation as
"doman -i18n=lang" is not flexible enough to dial with a directory full of man
pages in different languages.

Reproducible: Always

Steps to Reproduce:

Created an attachment (id=153375) [details]
doman-langsufix.patch

A patch for doman that will handle the following cases (the same ones
dh_installman can handle):
foo.1    -> man/man1/foo.1
foo.lang.1 -> man/lang/man1/foo.1

where ${lang} can be a two letter language code (ej: 'es') or a two letter
language code followed by a variant (ej: 'es_MX').

please do not use string replacements like that ... too much of a possibility
of hitting false positives

add a case to trim the lang from the end of the name only

(In reply to comment #2)
> please do not use string replacements like that ... too much of a possibility
> of hitting false positives

I think in this case the string replacement is reasonably safe, as I match for
\.xx(_XX)?\. and man pages are not allowed to have dots in their names. But You
are right, ${x/.${manlang}./.} or maybe ${x/.${manlang}.${suffix}/.${suffix}}
is a lot safer (Note: bash's string substitution '.' matches only '.'), so I'll
update the patch to that.

> add a case to trim the lang from the end of the name only

Sorry I don't get what do you mean by that case, could you please elaborate
some more or give me an example?

PS: I'll update the patch once the second part of the request is clear to avoid
spamming bugzilla.

what i meant was to use the % operator so that you only trim from the end of
the string ... i think some of the code there is already doing similar stuff

Created an attachment (id=154375) [details]
doman-langsufix.patch

Updated patch as requested by SpanKY.

Thanks, I've just committed a version of your patch which makes use of bash's
=~ operator and corresponding $BASH_REMATCH array:

-       mandir=${i18n}man${suffix:0:1}
+       if [[ $x =~ (.*)\.([a-z][a-z](_[A-Z][A-Z])?)\.(.*) ]] ; then
+               name=${BASH_REMATCH[1]##*/}.${BASH_REMATCH[4]}
+               mandir=${BASH_REMATCH[2]}/man${suffix:0:1}
+       else
+               name=${x##*/}
+               mandir=${i18n}man${suffix:0:1}
+       fi

i'd suggest we avoid the =~ operator as it historically breaks during bash
upgrades ... but hopefully most of that has finished now that =~ has been out
for a while ...

That crossed my mind too. However, that's not the only thing that can break
with a bash upgrade. Something like bug 190128 could also happen again. It's
not the end of the world if something breaks like that (hopefully it won't
though). If any kind of severe breakage occurs, we'll have to do like we did
for bug 190128 and use blockers to prevent bad combinations of portage & bash.
Blockers like those aren't nearly as annoying as they used to be, since current
versions of portage can solve them automatically by adjusting merge order
(upgrade portage first, then bash).

Fixed in or before 2.2_pre8