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 attachment 153375 [details, diff] 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 attachment 154375 [details, diff] 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
