some man pages we translate have the following: .SH OPTIONS .I Gawk accepts the following options. Standard options are listed first, followed by options for .I gawk extensions, listed alphabetically by short option. .TP .BI \-f " program-file\fR,\fP "\c .BI \-\^\-file " program-file" Read the \*(AK program source from the file The "\c" causes the following (fatal) warning, i.e. no output: Escape sequence \c encountered. This is not completely handled yet. As a workaround I'm currently considering patching the source files "on the fly" to get the build to proceed. Until recently I was ignoring this message, because it implies that just some detail is not properly handled; however I did not realize that the build fails. (This is now urgent as some man pages build for bullseye, but no longer for bookworm, and once bullseye translations are gone, the entire translation is gone - no good). So there are two solutions: a) Reword the message to clearly state that the build is aborted b) Ignore the escape sequence (or properly handle it) change, i.e. actually build the pot file In this case, the warning might remain as is. Obviously, I would prefer b) (and potentially a sane workaround until then).
This is a wrong use of '\c', as its purpose is to join the output of two macros _without_ an intervening space character. So remove ' ' and '\c', changing .BI \-f " program-file\fR,\fP "\c to .BI \-f " program-file\fR,\fP"
Hello Bjarni,
I'm currently looking for the best regular expressions to catch all
occurences on the fly before converting.
And I'll report this to the source package, i.e. the author of this
page. This was introduced recently, i.e. in bullseye it is not
present.
Thanks for the quick analysis.
Greetings
Helge
Hello Bjarni,
Thanks, this make the build proceed, however, now it dies in the
following line:
.TP
.BI \-F " fs\fR, \fP"\c
.BI \-\^\-field-separator " fs"
Escape sequence \c encountered. This is not completely handled yet.
Note that here there is no space before the "
Removing also this (and subsequent) "\c" makes the build proceed,
however, in other files "\c" exists as well and I'm vary of removing
the as well.
I *think* the difference is that the failing lines have a ".BI" at the
beginnig. (And the non failing do not.) Does this make sense to you?
Thanks for your support!
Greetings
Helge
My change is wrong as I ignored the 'TP' macro, which uses only one (logical) line, but I made two physical lines. The simples change is to join the two lines with an '\', and put the space after the comma (punctuation), so .BI \-f " program-file\fR, \fP" \ \-\^\-file " program-file" One can construct a one line expression by including a temporary roman font change in one of the arguments for a two-fonts macro. I find it is best to include the space with the punctuation, so .BI \-f " program-file\fR, \fP" \-\^\-file " program-file" Transform this to one line (as the arguments are of short length) .TP .BI \-F " fs\fR, \fP" \-\^\-field-separator " fs"
Hello Bjarni,
.TP
.BI something\c
.BI somethingelse
needs to become
.TP
.BI something\
somethingelse
The problem is, that I use sed to fix this (until either upstream
fixes its man page or po4a has a workaround). (And I don't care about
space etc, the translator will need to make her own anyway.)
From trial and error I noticed the the second ".BI" does not cunfuse
po4a.
So I check if
.BI something\c → .BI something\
I unique enough to only apply to the two man pages using it and does
th trick.
Thanks for your efforts!
Greetings
Helge
[Debian BTS users: please CC the groff list on replies.]
At 2023-05-29T19:15:32+0000, Bjarni Ingi Gislason wrote:
That background is pretty important, because nothing you said after that
point in the message made any sense to me.
So I'll quote Helge Kreutzmann's original bug report:
It is important for programs that interpret man pages to handle this.
It should be given some priority. But I wouldn't be surprised if one
reason it hasn't already been is that there has historically been a lot
of mystique and folkore around the meaning of this roff escape sequence.
Some quotes from groff_man_style(7) from the forthcoming groff 1.23.0
release (now at release candidate 4) might help.[1]
.TP [indentation]
Set a paragraph with a leading tag, and the remainder of the
paragraph indented. A one-line input trap is planted; text on
the next line, which can be formatted with a macro, becomes the
tag, which is placed at the current left margin. The tag can be
extended with the \c escape sequence. Subsequent text is
indented by indentation, if specified, and by a default amount
otherwise; see subsection "Horizontal and vertical spacing"
below. If the tag is not as wide as the indentation, the
paragraph starts on the same line as the tag, at the applicable
indentation, and continues on the following lines. Otherwise,
the descriptive part of the paragraph begins on the line
following the tag.
[...]
groff's own command-line interface serves to illustrate most of the
specimens of synopsis syntax one is likely to encounter.
.SY groff
.RB [ \-abcCeEgGijklNpRsStUVXzZ ]
.RB [ \-d\~\c
.IR cs ]
.RB [ \-d\~\c
.IB name =\c
.IR string ]
.RB [ \-D\~\c
.IR enc ]
(and so on similarly)
[...]
Several features of the above example are of note.
[...]
o The output line continuation escape sequence \c is used with font
style alternation macros to allow all three font styles to be set
without (breakable) space among them; see subsection "Portability"
below.
[...]
\c End a text line without inserting space or attempting a break.
Normally, if filling is enabled, the end of a text line is
treated like a space; an output line may be broken there (if
not, an adjustable space is inserted); if filling is disabled,
the line will be broken there, as in .EX/.EE examples. The next
line is interpreted as usual and can include a macro call
(contrast with \newline). \c is useful when three font styles
are needed in a single word, as in a command synopsis.
.RB [ \-\-stylesheet=\c
.IR name ]
It also helps when changing font styles in .EX/.EE examples,
since they are not filled.
.EX
$ \c
.B groff \-T utf8 \-Z \c
.I file \c
.B | grotty \-i
.EE
Now, quoting Bjarni's claims in the bug log, and adding in a bit more of
the original context...
This is bad advice in a couple of respects. Because you have only two
(space-separated) words before a break, there's no need for \c at all.
I would document the option as follows.
.TP
.BI \-f " program-file"
.TQ
.BI \-\-file " program-file"
Read the AWK program source from the file
.I program-file,
I made some other changes while I was at it.[2]
The other problem is that Bjarni's advice introduced a bunch of
superfluous italic correction escape sequences. There is absolutely no
reason to do this when (1) you're abutting italic text with _space_ and
(2) you're using groff man(7)'s font alternation macros, which take care
of italic corrections _for_ you, as they are documented to do.
Quoting groff_man_style(7) again:
Unlike the above font style macros, the font style alternation
macros below set no input traps; they must be given arguments to
have effect. Italic corrections are applied as appropriate. If a
space is required within an argument, first consider whether the
same result could be achieved with as much clarity by using single-
style macros on separate input lines. When it cannot, double-quote
an argument containing embedded space characters. Setting all three
different styles within a word presents challenges; it is possible
with the \c and/or \f escape sequences. See subsection
"Portability" below for approaches.
I'm attaching an abbreviated demonstration of my changes. I tested it
with groff Git HEAD, groff 1.22.4, DWB 3.3 nroff, and Heirloom Doctools
nroff.
Bjarni, please do not offer yourself as an authority on correct man page
composition when you don't know what you're talking about and have filed
bug reports complaining of that fact.
https://savannah.gnu.org/bugs/?64238
Regards,
Branden
[1] https://mail.gnu.org/archive/html/groff/2023-04/msg00135.html
[2] I used groff man(7)'s permissively licensed `TQ` extension,[3] took
out the hair space escape sequence, and switched from `IR` to `I`
when setting a metasyntactic variable in running text with adjacent
punctuation because it looks better when typeset. But all of these
are matters of taste, not correctness.
[3] The gawk(1) page author works around it by doing the `PD 0` push-pop
trick with another `TP` call. This is perfectly portable as far as
I know, if mystifying to the novice man(7) author. I find `TQ`
cleaner. I feel that `PD` tricks will be made unnecessary with some
semantic/structural tagging reforms to man(7) I have in mind.
https://lists.gnu.org/archive/html/groff/2022-12/msg00075.html
https://lists.gnu.org/archive/html/groff/2022-12/msg00078.html
But those will have to wait for groff 1.24...
At 2023-05-29T15:17:34-0500, G. Branden Robinson wrote: [...] Sure as the sunrise, I forgot the attachment. Regards, Branden
Hello Branden,
thanks for your help.
Done.
Ok, then the proper fix is in po4a, so this bug report is truely valid
against po4a.
So a fix is in gawk (upstream)? That is great. Thanks.
Thanks for your help.
Greetings
Helge
[added Arnold Robbins to CC list] At 2023-05-30T17:39:20+0200, Helge Kreutzmann wrote: Yes. I'm afraid not; the only GNU project to which I have commit privileges is groff. I'm looping in the longtime Gawk maintainer for his feedback. I'm not sure his tastes in man page style are the same as mine anyway. :) The background is at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036826>. Regards, Branden
severity 1036826 important
thanks
Hello Martin,
you have been quite in this discussion. \c occurs in more and more man
pages, and currently the build fails for them. In turn, they are no
longer translated.
Could you kindly check if you could add support for "\c" or is there
another workaround?
Thanks for your support!
Greetings
Helge
severity 1036826 normal thanks please don't abuse the severity. po4a is not only for groff, and many groff pages do work without it. Instead, I'd appreciate if you could do a merge request with a test file, along with the expected output. It'd save me the time to dig into the discussion of this bug. I'm not saying that I won't fix it w/o this test case. I'm just saying that providing a test case is a better approach to speedup the fix than severity abuse. Thanks for your help, Mt Le samedi 09 mars 2024 à 12:39 +0000, Helge Kreutzmann a écrit :
Hello Martin,
Am Sun, Mar 10, 2024 at 10:14:20PM +0100 schrieb Martin Quinson:
I hope explaining the test file in this bug is fine as well, because
I'm not sure what to do exactly merge and how.
The test case is groff(1) as it is in Debian unstable:
$ LC_ALL=C po4a-updatepo -f man --no-deprecation --option groff_code=verbatim --option generated --option untranslated="}1,Ds,zY,zZ,Ee,ES,dT,FN,NE,NS,EX,EE,Id,rstReportMargin,INDENT,UNINDENT,UN,a.RE,\|" --option unknown_macros=untranslated --master groff.1 -M utf-8 -p test.pot
groff.1:2279: (po4a::man)
Escape sequence \c encountered. This is not completely
handled yet.
And there is no output.
If I do a crude preprocessing, it kind of works:
$ cat groff.1 | perl -p -e 's/\\c\n//' > groff.test.1
$ LC_ALL=C po4a-updatepo -f man --no-deprecation --option groff_code=verbatim --option generated --option untranslated="}1,Ds,zY,zZ,Ee,ES,dT,FN,NE,NS,EX,EE,Id,rstReportMargin,INDENT,UNINDENT,UN,a.RE,\|" --option unknown_macros=untranslated --master groff.test.1 -M utf-8 -p test.pot
$ wc -l test.pot
3157 test.pot
I hope this helps you working on this, together with the discussion in
this bug.
Thanks for your support!
Greetings
Helge
tag 1036826 fixed-upstream thanks Hello Helge, I think I fixed this bug upstream, and it will be part of the next release, later this month. I did not implement a full support for \c since it's difficult in the current code base, but at least the groff.1 page proceeds. If you have other failures from other pages, please tell me so that I can check whether my fix is enough even before the release. Thanks for your help and patience, Mt Le jeudi 14 mars 2024 à 19:56 +0000, Helge Kreutzmann a écrit :
Hello Martin,
Am Fri, May 10, 2024 at 06:55:38PM +0200 schrieb Martin Quinson:
This is very good news. Thank you very much!
I can do so tomorrow afternoon, if this has time until then (I have
limited access atm).
The thanks is on my side!
Greetings
Helge
tag 1036826 fixed-upstream thanks Hello Helge, I think I fixed this bug upstream, and it will be part of the next release, later this month. I did not implement a full support for \c since it's difficult in the current code base, but at least the groff.1 page proceeds. If you have other failures from other pages, please tell me so that I can check whether my fix is enough even before the release. Thanks for your help and patience, Mt Le jeudi 14 mars 2024 à 19:56 +0000, Helge Kreutzmann a écrit :
Hello Martin,
Am Fri, May 10, 2024 at 06:58:17PM +0200 schrieb Martin Quinson:
Thank you very much, I'm looking forward to the release.
I checked with the documentation base from manpages-l10n. The
following pages are failing (with the current po4a):
* groff (as reported)
* credentials.7 (as of Debian unstable)
* mkosi.1 (only from OpenSUSE tumbleweed, page attached (compressed))
* afmtodit.1 (as of Debian unstable)
* And it also fail(ed) in mkpasswd.1 (as of Debian unstable), see
Debian #1036908
Again, thanks from my side.
Greetings
Helge
Hello Martin, now with the attachement. Am Sun, May 12, 2024 at 08:36:36AM +0000 schrieb Helge Kreutzmann:
Hello Helge, Le samedi 11 mai 2024 à 03:31 +0000, Helge Kreutzmann a écrit : No rush. If some problems presist, I'll try to fix it afterward. Enjoy your stay, Mt
Hello Martin,
Am Sun, May 12, 2024 at 07:05:32PM +0200 schrieb Martin Quinson:
Did you receive my e-mail from this morning, where I compiled the
remaining examples I'm aware of?
Greetings
Helge
Le dimanche 12 mai 2024 à 17:26 +0000, Helge Kreutzmann a écrit : Yes I did (sorry for answering earlier before reading all mails in inbox), but I did not dig into it yet. Thanks, Mt
We believe that the bug you reported is fixed in the latest version of
po4a, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1036826@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Dr. Tobias Quathamer <toddy@debian.org> (supplier of updated po4a package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Thu, 30 May 2024 14:14:41 +0200
Source: po4a
Architecture: source
Version: 0.72-1
Distribution: unstable
Urgency: medium
Maintainer: Martin Quinson <mquinson@debian.org>
Changed-By: Dr. Tobias Quathamer <toddy@debian.org>
Closes: 1022216 1036824 1036826
Changes:
po4a (0.72-1) unstable; urgency=medium
.
* New upstream version 0.72
- po4a-updatepo:
Do not pass empty PO files to msgmerge, as it stumbles on such things
when the POT file has UTF chars in the msgids. (Closes: #1022216)
- Documentation:
Revamp the po4a(7) document now that the po4a-scripts are deprecated.
Explain why they are, and don't mention them in the described
workflow. (Closes: #1036824)
- Man/Groff:
Properly handle \c escape sequence in .TP parameters (Closes: #1036826)
* Update d/copyright
* debian/copyright: use spaces rather than tabs to start continuation lines.
Changes-By: lintian-brush
Fixes: lintian: tab-in-license-text
See-also: https://lintian.debian.org/tags/tab-in-license-text.html
* Add upstream metadata
* Update Standards-Version to 4.7.0, no changes needed
* Fix double slash in d/watch URL
Checksums-Sha1:
bab48761d412c7b1b03a719d6872b7563afe7b56 2160 po4a_0.72-1.dsc
a499d7d29c5e16c21f2f4533340aa8e13321931d 3991368 po4a_0.72.orig.tar.gz
65e6681cc85482a0c167beeeac8e299729f1381c 13616 po4a_0.72-1.debian.tar.xz
4c0e5c236c6de24e26539256fa743519f668a125 7959 po4a_0.72-1_amd64.buildinfo
Checksums-Sha256:
973bdaf9c18226c326ac818e1205626cdbe7b4da13b8b803d95a1f66b91cd88e 2160 po4a_0.72-1.dsc
17fbd720099e067a5877037420dce11f10a4efcd1a174eae5d17cf615ac1d21c 3991368 po4a_0.72.orig.tar.gz
0b1f6e645e8b3d0f2723a5aecc589c8951636f2d6bb8bc0fea31f9e6589a1986 13616 po4a_0.72-1.debian.tar.xz
afba8e8b59aa36b212c320438d3a922ef1402f8910aca1970ade84f0f09e83e6 7959 po4a_0.72-1_amd64.buildinfo
Files:
8f3ed38824ff49d502ab69bd25dfce14 2160 text optional po4a_0.72-1.dsc
c67021fe29a29bc17bec7ad30fd5a6ae 3991368 text optional po4a_0.72.orig.tar.gz
299f853c8ac52eb6b71754c4e24ddedf 13616 text optional po4a_0.72-1.debian.tar.xz
268cee3c437fd5fef3f46b701d151374 7959 text optional po4a_0.72-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE0cuPObxd7STF0seMEwLx8Dbr6xkFAmZYcLcACgkQEwLx8Dbr
6xnEyQ//QW2kGCAKMBrk56LcWhfYUPN1qM6MQR4J+AbJsoiLBbdeVXkleHUsMCg2
HZHeP53kU4grceer/ThiI3ppt2QuCFWzhBcacAN0PuZi86VCkH6lHJApta1Ul9Mt
JsSCI/P5n1WpwKsljAxcmUU9SnAzc1AvCe8zZMXvUVT1LM+ruBcM5CQe+sZG/fIl
qxsIEiNVn3yGZcWo1abdXvq+BX/8RQhMsCsLEY6HOJBAHx8NjZleD32xQ4QDVDdP
Hai8WI7nbU6dOwnXILmhNpFBVkm3W41enFFpzWRZ3nPU+dZrqlAkwCGuh2EJLQ1X
+zn2jVbA9Aq1PLf3xZRDcFWWUFI2DC2/uAZfGGu5rpnCJB+ZFvWvl9cbWsb/n1OY
+zdGb+P3zjjGacmqIoW5HIElSfgWnFlCvXoQtkUd4+PQXunGWKY/d4b1wb68C86J
kGnds7D4gprI5fm7AsyqyI75urjdeTn1bSHqk+P3O6iqoBe1HBX8Y2SQzEEEWbA7
nOgF8eKVTCDs8rLQ19oMtleih4MQZcDHrgROpjBz2J3cLk3hOTOPmT92lkodUxQ/
QQG7/su6LqwoKJIVY2U5+1xs3PSYWBNWoVQjJ4kNVyACrIemvFlNZEG+OZGMOvtI
ApqLjl6xc3w1BME2zEyrUJPFxT2h+42ObpARbIRhzEWBMvxfLY8=
=Q4Eu
-----END PGP SIGNATURE-----
Hello Martin,
Am Sun, May 12, 2024 at 08:36:36AM +0000 schrieb Helge Kreutzmann:
Groff.1 works now, but all others listed here still fail. Is this
expected?
(Po4a 0.72 just hit unstable, so I tried them out).
Greetings
Helge
reopen 1036826 thanks Hello, Le jeudi 30 mai 2024 à 19:05 +0000, Helge Kreutzmann a écrit : No it's not. I'll look into it. Sorry, Mt
Hello Martin,
Am Fri, May 31, 2024 at 10:33:08AM +0200 schrieb Martin Quinson:
Thank you very much!
Greetings
Helge
Hello Martin,
gawk(1) is also affected by this bug (only the Debian version,
though).
Greetings
Helge
Hello Martin,
another man page appeared, using \c, namely
update-openssh-known-hosts(8):
.SH AUTHORS
Timo Weingärtner \c
.MT timo@tiwe.de
.ME \c.
Currently, I simply remove the \c to get the man page
to be processed by po4a (as workaround).
Greetings
Helge
We believe that the bug you reported is fixed in the latest version of
whois, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1036826@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Marco d'Itri <md@linux.it> (supplier of updated whois package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Mon, 05 May 2025 02:57:37 +0200
Source: whois
Architecture: source
Version: 5.6.0
Distribution: unstable
Urgency: medium
Maintainer: Marco d'Itri <md@linux.it>
Changed-By: Marco d'Itri <md@linux.it>
Closes: 1036826 1094208
Changes:
whois (5.6.0) unstable; urgency=medium
.
* Fixed the mangling of RADB queries with commands.
* Implemented the parsing of more variants of ARIN's ReferralServer
field.
* Implemented following the APNIC pseudo-referrals.
* Added the .ad and .za TLD servers.
* Updated the .ao, .bz, .gi, .gq, .gr, .gw, .lc, .md, .pn, .pr, .uy, .vc,
.info, .mobi, .ελ (.xn--qxam, Greece) and .გე (.xn--node, Georgia) TLD
servers.
* Added 2410::/12.
* Removed 7 new gTLDs which are no longer active.
* Cleaned up the markup of the man pages, courtesy of Bjarni Ingi
Gislason. (Closes: #1036826, #1094208)
Checksums-Sha1:
c1abaf5cf3360852074aea3726f6dc9f72ae7703 921 whois_5.6.0.dsc
b5fc2bd607ff2ac6285cc4478dca3cf26c0cfbc5 91912 whois_5.6.0.tar.xz
6d0e67b43d8ceee6ae15c13f6782725e26bfa344 5372 whois_5.6.0_amd64.buildinfo
Checksums-Sha256:
374c548f63b12e227c1d9c1f1416654aba8d0aececa0ec2ac9d85d0218ea45c5 921 whois_5.6.0.dsc
4229f8b55c75f698ef6d01c8eb2ee880302a6ec63b7b8787e12400295b22f3e4 91912 whois_5.6.0.tar.xz
b984ba0168dd2bca7384db2fe3c8b681a308d3b4a208cd2fea8a1ec93c780099 5372 whois_5.6.0_amd64.buildinfo
Files:
b1c2ad83dc6494aa0c02b5dc1b0928dc 921 net standard whois_5.6.0.dsc
529a0615d6f924ac7b0051e7a8ecd829 91912 net standard whois_5.6.0.tar.xz
496380a2319656ecc5102ec99900a754 5372 net standard whois_5.6.0_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQQnKUXNg20437dCfobLPsM64d7XgQUCaBgNVgAKCRDLPsM64d7X
gcmHAQDstO6XrzD7qfQ3bJ/Bbz3L8VYpuAxBEO3zWAlKBwEsQgEAj1cLcNUUw43H
FF9M2Msg/9xjiKWYLh2rPrSti8Pj0QY=
=ayLe
-----END PGP SIGNATURE-----
Hello Martin,
the latest bash now has the following sequences:
.TP
A short script or \c
.Q recipe " \c"
which exercises the bug
.B Bash
can be configured to be
.SM POSIX\c
-conformant by default.
As usual, I try to workaround in manpages-l10n, my sed
expression gets longer and longer …
Greetings
Helge