[bug #59745] Issues in findutils manpages

[Bernhard Voelker]

Update of bug #59745 (project findutils):

                Category:                    find => documentation          
                  Status:                    None => Code Review            
             Assigned to:                    None => berny                  

    _______________________________________________________

Follow-up Comment #6:

Thank you, Helge, very much for this report.
It's very important to steadily improve the documentation,
so this kind of feedback is appreciated very much.

I have prepared some patches to which I'll refer to in the discussion below.
While looking at all of the man pages of the findutils package for
comparison,
I've found some other things to improve as well.

 * [PATCH 01/12] xargs.1: improve indentation of list of exit statuses
 * [PATCH 02/12] xargs.1: remove deprecated .PD macro
 * [PATCH 03/12] updatedb.1: avoid Texinfo macro in man page
 * [PATCH 04/12] doc: harmonize the end of the man pages
 * [PATCH 05/12] locate.1: improve formatting in BUGS section
 * [PATCH 06/12] doc: avoid starting sentences with an option
 * [PATCH 07/12] find.1: set filenames in italics
 * [PATCH 08/12] find.1: fix and improve some more markups
 * [PATCH 09/12] find.1: improve formatting of EXAMPLES section
 * [PATCH 10/12] doc: minor grammar change about a change in the past
 * [PATCH 11/12] find.1: avoid confusing brackets a sentence
 * [PATCH 12/12] find.1: fix various other issues

The last one is in the name of you, Andreas, unless you object.

> Man page: find.1
> Issue: superfluous blanks
> 
> "Descend at most I<levels> (a non-negative integer) levels of directories "
> "below the starting-points.  B<-maxdepth 0> means only apply the tests and
"
> "actions to the starting-points themselves."
There are no superfluous blanks here: the "double-blank-after-dot" is
correct and yields better readability.  As you wrote - just ignore them.

Regarding the 2 blanks before "B<-maxdepth 0>":
Indeed, starting a sentence with an option is bad style - fixed with:

 * [PATCH 06/12] doc: avoid starting sentences with an option

> --
> Man page: find.1
> Issue: Are the \\| in the argument name correct?
> 
> "The + and - prefixes signify greater than and less than, as usual; i.e.,
an
> "
> "exact size of I<n> units does not match.  Bear in mind that the size is "
> "rounded up to the next unit.  Therefore B<-size -1M> is not equivalent to
> B<-"
> "size -1\\|048\\|576c>.  The former only matches empty files, the latter "
> "matches files from 0 to 1,048,575 bytes."
Bjarni Ingi Gislason - another translator - introduced them recently:  ;-)
https://git.savannah.gnu.org/cgit/findutils.git/commit/?id=a0fada430a89

They create a 1/6th em space, and therefore act as a visual thousands-
separator to ease reading of larger numbers.

Andreas patch would remove them:

> -.BR "\-size \-1\|048\|576c".
> +.BR "\-size \-1048576c".

I disagree to remove them until we have consensus about it.

> --
> Man page: find.1
> Issue: Missing closing bracket
> 
> "This variant of the B<-exec> action runs the specified command on the "
> "selected files, but the command line is built by appending each selected "
> "file name at the end; the total number of invocations of the command will
be
> "
> "much less than the number of matched files.  The command line is built in
"
> "much the same way that B<xargs> builds its command lines.  Only one
instance
> "
> "of `{}' is allowed within the command, and (when B<find> is being invoked
"
> "from a shell) it should be quoted (for example, \\(aq{}\\(aq) to protect it
"
> "from interpretation by shells.  [...]

As mentioned by Andreas, there is no missing closing bracket.
The \(aq which yields an Apostrophe quote, see "Special characters" in
https://man7.org/linux/man-pages/man7/groff.7.html .
The text is "... quoted (for example, '{}') to ...".

Still, having 2 brackets in one sentence disturbs the easy reading.
Fixed in:

 * [PATCH 11/12] find.1: avoid confusing brackets a sentence

Now to Andreas' patch:

> @@ -1516,10 +1516,7 @@ The device number on which the file exists (the
st_dev field of struct stat), in decimal.
>  .IP %f
>  Print the basename; the file's name with any leading directories
> -removed (only the last element).  For
> -.B /,
> -the result is
> -.B /.
> +removed (only the last element).  For \fB/\fR, the result is \fB/\fR.
>  See the
>  .B EXAMPLES
>  section for an example.

I'd prefer the more readable .BR on a separate line over the inline \fB...\fP
where possible.  See man-pages(7):

  [...]
  The preferred way to write this in the source file is:
      .BR fcntl ()
  (Using this format, rather than the use of "\fB...\fP()" makes it
  easier to write tools that parse man page source files.)

> @@ -1535,9 +1532,8 @@ File's numeric group ID.
>  Dirname; the Leading directories of the file's name (all but the last
>  element).  If the file name contains no slashes (since it is in the
>  current directory) the %h specifier expands to `.'.  For files which
> -are themselves directories and contain a slash (including
> -.B /,
> -), %h expands to the empty string.  See the
> +are themselves directories and contain a slash (including \fB/\fR),
> +%h expands to the empty string.  See the
>  .B EXAMPLES
>  section for an example.
>  .IP %H

Likewise: --> .BR / ,

> @@ -1618,11 +1614,10 @@ character.  In some locales, it may hide your door
keys, while in
>  others it may remove the final page from the novel you are reading.
>  
>  The %m and %d directives support the
> -.B #
> -,
> -.B 0
> +.BR # ,
> +.BR 0
>  and
> -.B +
> +.BR +
>  flags, but the other directives do not, even if they
>  print numbers.  Numeric directives that do not support these flags
>  include

.BR requires 2 arguments, so it should read ".B 0" and ".B +".

> @@ -1906,9 +1901,7 @@ are all supported.
>  
>  .P
>  The POSIX standard specifies parentheses `(', `)', negation `!' and the
> -`and' and `or' operators (
> -.BR \-a ,
> -.BR \-o ).
> +`and' and `or' operators (\fB\-a\fR, \fB\-o\fR).
>  .P
>  All other options, predicates, expressions and so forth are extensions
>  beyond the POSIX standard.  Many of these extensions are not unique to

Also here: use .B instead of inline \fB.
Here, 'make syntax-check' would complain about repetition of the word "and",
so I'd write the operators in uppercase (like in other places already)
and just separated by a '/' .


  [...] the logical AND/OR operators [...]


Finally, the ordering of the man page references in the "SEE ALSO" section
went into:

 * [PATCH 04/12] doc: harmonize the end of the man pages

What do you think?

Have a nice day,
Berny





(file #50589)
    _______________________________________________________

Additional Item Attachment:

File name: fu-patches.tar.gz              Size:19 KB
    <https://file.savannah.gnu.org/file/fu-patches.tar.gz?file_id=50589>



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59745>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/