Package: libcap2-bin
Version: 1:2.66-5
Severity: minor
Tags: patch

   * What led up to the situation?

     Checking for defects with

[test-][g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -ww -b -z < "man page"

  ["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).

  [The fate of "test-nroff" was decided in groff bug #55941.]

   * What was the outcome of this action?

troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':649: macro 'BR'
troff: backtrace: file '<stdin>':7
troff:<stdin>:7: warning: trailing space in the line

   * What outcome did you expect instead?

     No output (no warnings).

-.-

  General remarks and further material, if a diff-file exist, are in the
attachments.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.11.2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libcap2-bin depends on:
ii  libc6    2.40-3
ii  libcap2  1:2.66-5

Versions of packages libcap2-bin recommends:
pn  libpam-cap  <none>

libcap2-bin suggests no packages.

-- no debconf information
  Any program (person), that produces man pages, should check the output
for defects by using (both groff and nroff)

[gn]roff -mandoc -t -ww -b -z -K utf8  <man page>

  The same goes for man pages that are used as an input.

  For a style guide use

  mandoc -T lint

-.-

  So any 'generator' should check its products with the above mentioned
'groff', 'mandoc',  and additionally with 'nroff ...'.

  This is just a simple quality control measure.

  The 'generator' may have to be corrected to get a better man page,
the source file may, and any additional file may.

  Common defects:

  Input text line longer than 80 bytes.

  Not removing trailing spaces (in in- and output).
  The reason for these trailing spaces should be found and eliminated.

  Not beginning each input sentence on a new line.
Lines should thus be shorter.

  See man-pages(7), item 'semantic newline'.

-.-

The difference between the formatted outputs can be seen with:

  nroff -mandoc <file1> > <out1>
  nroff -mandoc <file2> > <out2>
  diff -u <out1> <out2>

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - "

instead of 'nroff -mandoc'

  Add the option '-t', if the file contains a table.

  Read the output of 'diff -u' with 'less -R' or similar.

-.-.

  If 'man' (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -b -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

30:.B --verbose
52:defaults to true when running via a TTY. The \fB--color\fI=false\fR

-.-.

Use the correct macro for the font change of a single argument or
split the argument into two.

40:.BR \-\-verbose

-.-.

Wrong distance between sentences in the input file.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

13:value(s) given on the command line. If no
17:is implied. A
23:format. The IAB tuple of capabilities is displayed between square
27:components. This is because the regular POSIX.1e text contains
28:information about the Inheritable flag already. This behavior can be
37:Displays usage information and exits. Note, modern Go runtimes exit
51:Colo[u]rs the targeted PIDs, if stdout is a TTY, in red. This option
52:defaults to true when running via a TTY. The \fB--color\fI=false\fR
53:argument will suppress this color. Piping the output into some other
56:If the supplied target cannot be found the exit status is 1. Should an
57:unrecognized option be provided, the exit status is 2. Otherwise,
75:Andrew G. Morgan <mor...@kernel.org>

-.-.

Split a punctuation mark from a single argument for a two-font macro

65:.BR cap_from_text(3),

-.-.

Output from "test-groff  -mandoc -t -K utf8 -rF0 -rHY=0 -ww -b -z ":

troff: backtrace: '/home/bg/git/groff/build/s-tmac/an.tmac':649: macro 'BR'
troff: backtrace: file '<stdin>':7
troff:<stdin>:7: warning: trailing space in the line

-.-.

  Additionally (general):

  Abbreviations get a '\&' added after their final full stop (.) to mark them
as such and not as an end of a sentence.

--- captree.8   2024-10-21 23:10:02.993474122 +0000
+++ captree.8.new       2024-10-21 23:24:41.964244337 +0000
@@ -4,40 +4,45 @@
 .SH NAME
 captree \- display tree of process capabilities
 .SH SYNOPSIS
-.BR captree " [OPTIONS] "
+.BR captree " [OPTIONS]"
 .RI [( pid | glob-name ") ...]"
 .SH DESCRIPTION
 .B captree
 displays the capabilities on the mentioned processes indicated by
 .IR pid " or " glob-name
-value(s) given on the command line. If no
+value(s) given on the command line.
+If no
 .I pid
 etc values are supplied,
 .IR pid =1
-is implied. A
+is implied.
+A
 .I pid
 value of 0 displays all the processes known to the kernel.
 .PP
 The POSIX.1e capabilities are displayed in double quotes in the
 .BR cap_from_text (3)
-format. The IAB tuple of capabilities is displayed between square
+format.
+The IAB tuple of capabilities is displayed between square
 brackets in the text format described in
 .BR cap_iab (3).
 Note, the IAB tuple text is omitted if it contains empty A and B
-components. This is because the regular POSIX.1e text contains
-information about the Inheritable flag already. This behavior can be
-overridden with the
-.B --verbose
+components.
+This is because the regular POSIX.1e text contains
+information about the Inheritable flag already.
+This behavior can be overridden with the
+.B \-\-verbose
 command line argument.
 .PP
 Optional arguments (which must precede the list of pid|glob-name
 values):
 .TP
 .B \-\-help
-Displays usage information and exits. Note, modern Go runtimes exit
-with status 0 in this case, but older runtimes exit with status 2.
+Displays usage information and exits.
+Note, modern Go runtimes exit with status 0 in this case,
+but older runtimes exit with status 2.
 .TP
-.BR \-\-verbose
+.B \-\-verbose
 Displays capability sets and IAB tuples even when they are empty, or
 redundant.
 .TP
@@ -49,12 +54,14 @@ infinite depth.
 .TP
 .BI \-\-colo[u]r =false
 Colo[u]rs the targeted PIDs, if stdout is a TTY, in red. This option
-defaults to true when running via a TTY. The \fB--color\fI=false\fR
+defaults to true when running via a TTY. The \fB\-\-color\fI=false\fR
 argument will suppress this color. Piping the output into some other
 program will also suppress the use of colo[u]r.
 .SH EXIT STATUS
-If the supplied target cannot be found the exit status is 1. Should an
-unrecognized option be provided, the exit status is 2. Otherwise,
+If the supplied target cannot be found the exit status is 1.
+Should an unrecognized option be provided,
+the exit status is 2.
+Otherwise,
 .B captree
 exits with status 0.
 .SH REPORTING BUGS
@@ -62,7 +69,7 @@ Please report bugs via:
 .TP
 https://bugzilla.kernel.org/buglist.cgi?component=libcap&list_id=1090757
 .SH SEE ALSO
-.BR cap_from_text(3),
+.BR cap_from_text (3),
 .BR capabilities (7),
 and
 .BR cap_iab (3).
@@ -72,4 +79,4 @@ examples, here:
 
    https://sites.google.com/site/fullycapable/captree
 .SH AUTHOR
-Andrew G. Morgan <mor...@kernel.org>
+Andrew G.\& Morgan <mor...@kernel.org>

Reply via email to