Bug 222439 – doman should support foo.lang.N filenames

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Yuri Vasilevski (RETIRED) 2008-05-16 21:16:26 UTC]

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:

[Comment 1 Yuri Vasilevski (RETIRED) 2008-05-16 21:17:13 UTC]

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').

[Comment 2 SpanKY 2008-05-17 03:21:53 UTC]

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

[Comment 3 Yuri Vasilevski (RETIRED) 2008-05-19 15:52:28 UTC]

(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.

[Comment 4 SpanKY 2008-05-22 01:51:01 UTC]

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

[Comment 5 Yuri Vasilevski (RETIRED) 2008-05-26 17:55:50 UTC]

Created attachment 154375 [details, diff]
doman-langsufix.patch

Updated patch as requested by SpanKY.

[Comment 6 Zac Medico 2008-05-27 23:10:54 UTC]

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

[Comment 7 SpanKY 2008-05-31 05:51:56 UTC]

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 ...

[Comment 8 Zac Medico 2008-05-31 18:45:10 UTC]

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).

[Comment 9 Marius Mauch (RETIRED) 2008-06-10 16:08:23 UTC]

Fixed in or before 2.2_pre8