bugfindutils - Bugs: bug #59745, Issues in findutils manpages

 
 

bug #59745: Issues in findutils manpages

Submitter:  Helge Kreutzmann <kreutzm>
Submitted:  Mon 21 Dec 2020 03:42:25 PM UTC
   
 
Category:  documentation Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  berny
Originator Name:  Open/Closed:  Closed
Release:  4.7.0 Fixed Release:  4.8.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 30 Dec 2020 08:37:42 PM UTC, comment #9: 

Thanks for the reviews.
I pushed the series together with a NEWS entry at:
https://git.sv.gnu.org/cgit/findutils.git/commit/?id=d7ababc40

Have a nice day,
Berny

Bernhard Voelker <berny>
Group administrator
Wed 30 Dec 2020 05:32:03 PM UTC, comment #8: 

No further comment from my side, thanks for the explanations!

Helge Kreutzmann <kreutzm>
Wed 30 Dec 2020 12:57:46 PM UTC, comment #7: 

comment #6:
[...]

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


Thanks for the explanation.

[...]

> What do you think?


Mainly a big thank you for improving the man pages and a bigger thank you for your explanations and pointers.

cu Andreas

~

Andreas Metzler <ametzler>
Wed 30 Dec 2020 11:21:06 AM UTC, 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)

Bernhard Voelker <berny>
Group administrator
Sun 27 Dec 2020 04:55:24 PM UTC, comment #5: 

comment #4:

> comment #3:

[...]

>> ametzler@argenau:/tmp/findtest$ touch fil1.c fil2.c
>> ametzler@argenau:/tmp/findtest$ find . -name *.c -print
>> find: paths must precede expression: `fil2.c'
>> find: possible unquoted pattern after predicate `-name'?

[...]
 

> Yes, I'm able to reproduce. But then my initial comment is (almost) correct, the man page text is (slightly) outdated. The man page says:
> find: paths must precede expression
> However, the output is:
> find: paths must precede expression: `fil2.c'


> (Note the extra colon and the '%s').


Hello Helge,

Well, we cannot reproduce the exact error message since it depends on the files present on the user's system. Imvho (not a native speaker) using the common part sans the misleading punctuation is the best choice here.

cu Andreas

Andreas Metzler <ametzler>
Sun 27 Dec 2020 03:58:41 PM UTC, comment #4: 

Hello Andreas,
comment #3:

> On 2020-12-27 Helge Kreutzmann wrote:
> > Follow-up Comment #2, bug #59745 (project findutils):


> > Actually, it doesn't even error out in my Debian unstable system
> > anymore, so I cannot check.
>
> This quoting issue only shows up if *.c is expanded by the shell because there
> are matching files in pwd:
> ~~~
> ametzler@argenau:~$ rm -rf /tmp/findtest/ ; mkdir /tmp/findtest/ ; cd /tmp/findtest/
> ametzler@argenau:/tmp/findtest$ find . -name *.c -print
> ametzler@argenau:/tmp/findtest$ touch fil1.c fil2.c
> ametzler@argenau:/tmp/findtest$ find . -name *.c -print
> find: paths must precede expression: `fil2.c'
> find: possible unquoted pattern after predicate `-name'?
> ametzler@argenau:/tmp/findtest$ echo find . -name *.c -print
> find . -name fil1.c fil2.c -print


Yes, I'm able to reproduce. But then my initial comment is (almost) correct, the man page text is (slightly) outdated. The man page says:
find: paths must precede expression
However, the output is:
find: paths must precede expression: `fil2.c'

(Note the extra colon and the '%s').

Sorry, the 2nd not the third line ...

Greetings

           Helge

Helge Kreutzmann <kreutzm>
Sun 27 Dec 2020 12:45:39 PM UTC, comment #3: 

Hello Helge,

On 2020-12-27 Helge Kreutzmann wrote:

> Follow-up Comment #2, bug #59745 (project findutils):

[...]

>>> Man page: find.1
>>> Issue: Superflous space in first line


>>> "The %m and %d directives support the B<#> , B<0> and B<+> flags, but the

[...]

>> The only duplicate spaces are right after the full stop. And afaict
>> this is done so throughout the manpage. No idea whether this is the
>> right thing to do.


> What this was referring to is the "B<#> , B<0>" part. The space before the
> comma, which is not present in other lists. The double space after the full
> stop is ignored by us, this is common.


Ah, thanks for the glasses. :-) Patch to be updated.

> ...
>>> "B<$ find . -name *.c -print>\n"
>>> "find: paths must precede expression\n"
>>> "find: possible unquoted pattern after predicate `-name'?\n"


> Looks correct in current GIT.


> Actually, it doesn't even error out in my Debian unstable system
> anymore, so I cannot check.


This quoting issue only shows up if *.c is expanded by the shell because there
are matching files in pwd:
~~~
ametzler@argenau:~$ rm -rf /tmp/findtest/ ; mkdir /tmp/findtest/ ; cd /tmp/findtest/
ametzler@argenau:/tmp/findtest$ find . -name *.c -print
ametzler@argenau:/tmp/findtest$ touch fil1.c fil2.c
ametzler@argenau:/tmp/findtest$ find . -name *.c -print
find: paths must precede expression: `fil2.c'
find: possible unquoted pattern after predicate `-name'?
ametzler@argenau:/tmp/findtest$ echo find . -name *.c -print
find . -name fil1.c fil2.c -print
~~~

cu Andreas

Andreas Metzler <ametzler>
Sun 27 Dec 2020 10:42:17 AM UTC, comment #2: 

Hello Andreas,
thanks for handling these issues. A few remarks from my side:

> Man page: find.1
> Issue: Superflous space in first line



 > "The %m and %d directives support the B<#> , B<0> and B<+> flags, but the "

> "other directives do not, even if they print numbers.  Numeric directives "
> "that do not support these flags include B<G>, B<U>, B<b>, B<D>, B<k> and "
> "B<n>.  The `-' format flag is supported and changes the alignment of a field
> "
> "from right-justified (which is the default) to left-justified."


The only duplicate spaces are right after the full stop. And afaict this is done so throughout the manpage. No idea whether this is the right thing to do.

What this was referring to is the "B<#> , B<0>" part. The space before the comma, which is not present in other lists. The double space after the full stop is ignored by us, this is common.
...
    > "B<$ find . -name *.c -print>\n"
    > "find: paths must precede expression\n"
    > "find: possible unquoted pattern after predicate `-name'?\n"
    > --


Look correct in current GIT.

Actually, it doesn't even error out in my Debian unstable system anymore, so I cannot check.

...

Helge Kreutzmann <kreutzm>
Sun 27 Dec 2020 08:02:51 AM UTC, comment #1: 

On 2020-12-21 Helge Kreutzmann <INVALID.NOREPLY@gnu.org> wrote:
[...]

> Secondly we translators see the manpages in the neutral po format,
> i.e. converted and harmonized, but not the original source (be it man,
> groff, xml or other). So we cannot provide a true patch (where
> possible), but only an approximation which you need to convert into
> your source format.


I think a couple of the issues reported are due to a broken conversion
process, I will mark them a such.

[...]

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


[conversion]

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


OK.

> 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.  The command is executed in the starting "
> "directory.  If any invocation with the `+' form returns a non-zero value as
> "
> "exit status, then B<find> returns a non-zero exit status.  If B<find> "
> "encounters an error, this can sometimes cause an immediate exit, so some "
> "pending commands may not be run at all.  This variant of B<-exec> always "
> "returns true."
> --


[conversion]
The man page uses \(aq to generate a printable single quote character.
Which afaict is the right thing to do.

> Man page: find.1
> Issue: Superflous space in first line


> "The %m and %d directives support the B<#> , B<0> and B<+> flags, but the "
> "other directives do not, even if they print numbers.  Numeric directives "
> "that do not support these flags include B<G>, B<U>, B<b>, B<D>, B<k> and "
> "B<n>.  The `-' format flag is supported and changes the alignment of a field
> "
> "from right-justified (which is the default) to left-justified."
> msgstr ""
> --


The only duplicate spaces are right after the full stop. And afaict this is done so throughout the manpage. No idea whether this is the right thing to do.

> Man page: find.1
> Issue: ( B<-a> -> (B<-a>


> "The POSIX standard specifies parentheses `(', `)', negation `!' and the "
> "`and' and `or' operators ( B<-a>, B<-o>)."
> --


OK.
 

> Man page: find.1
> Issue: wrong order of entries according to man-pages(7)


> "B<locate>(1), B<locatedb>(5), B<updatedb>(1), B<xargs>(1), B<chmod>(1), "
> "B<fnmatch>(3), B<regex>(7), B<stat>(2), B<lstat>(2), B<ls>(1), B<printf>(3),
> "
> "B<strftime>(3), B<ctime>(3)"
> --

OK

> Man page: find.1
> Issue: The third line is different in current testing as of 2016-08-08 &&
> 2018-04-07


> "B<$ find . -name *.c -print>\n"
> "find: paths must precede expression\n"
> "find: possible unquoted pattern after predicate `-name'?\n"
> --


Look correct in current GIT.

> Man page: find.1
> Issue: `strftime' -> B<strftime>(3)


> "File's last access time in the format specified by I<k>, which is either `@'
> "
> "or a directive for the C `strftime' function.  The following shows an "
> "incomplete list of possible values for I<k>.  Please refer to the "
> "documentation of `strftime' for the full list.  Some of the conversion "
> "specification characters might not be available on all systems, due to "
> "differences in the implementation of the `strftime' library function."
> msgstr ""
> --


I could not find a hard rule for this, but imho adding (3) and bold text
decreases readability.

> Man page: find.1
> Issue 1: B</,> -> B</>,
> Issue 2: B</.> -> B</>.


> "Print the basename; the file's name with any leading directories removed "
> "(only the last element).  For B</,> the result is B</.> See the B<EXAMPLES>
> "
> "section for an example."
> --


ok

> Man page: find.1
> Issue: B</,> ), -> B</> ),


> "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 B<EXAMPLES> section for an example."


ok.

cu Andreas

Andreas Metzler <ametzler>
Mon 21 Dec 2020 03:42:25 PM UTC, original submission:  

Dear findutils maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including findutils) as
well for a large variety of target languages.

During their work translators notice different possible issues in the
original (english) man pages. Sometimes this is a straightforward
typo, sometimes a hard to read sentence, sometimes this is a
convention not held up and sometimes we simply do not understand the
original.

We use several distributions as sources and update regularly (at
least every 2 month). This means we are fairly recent (some
distributions like archlinux also update frequently) but might miss
the latest upstream version once in a while, so the error might be
already fixed. We apologize and ask you to close the issue immediately
if this should be the case, but given the huge volume of projects and
the very limited number of volunteers we are not able to double check
each and every issue.

Secondly we translators see the manpages in the neutral po format,
i.e. converted and harmonized, but not the original source (be it man,
groff, xml or other). So we cannot provide a true patch (where
possible), but only an approximation which you need to convert into
your source format.

Finally the issues I'm reporting have accumulated over time and are
not always discovered by me, so sometimes my description of the
problem my be a bit limited - do not hesitate to ask so we can clarify
them.

I'm now reporting the errors for your project. If future reports
should use another channel, please let me know.

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."
--
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."
--
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.  The command is executed in the starting "
"directory.  If any invocation with the `+' form returns a non-zero value as "
"exit status, then B<find> returns a non-zero exit status.  If B<find> "
"encounters an error, this can sometimes cause an immediate exit, so some "
"pending commands may not be run at all.  This variant of B<-exec> always "
"returns true."
--
Man page: find.1
Issue: Superflous space in first line

"The %m and %d directives support the B<#> , B<0> and B<+> flags, but the "
"other directives do not, even if they print numbers.  Numeric directives "
"that do not support these flags include B<G>, B<U>, B<b>, B<D>, B<k> and "
"B<n>.  The `-' format flag is supported and changes the alignment of a field "
"from right-justified (which is the default) to left-justified."
msgstr ""
--
Man page: find.1
Issue: ( B<-a> -> (B<-a>

"The POSIX standard specifies parentheses `(', `)', negation `!' and the "
"`and' and `or' operators ( B<-a>, B<-o>)."
--
Man page: find.1
Issue: wrong order of entries according to man-pages(7)

"B<locate>(1), B<locatedb>(5), B<updatedb>(1), B<xargs>(1), B<chmod>(1), "
"B<fnmatch>(3), B<regex>(7), B<stat>(2), B<lstat>(2), B<ls>(1), B<printf>(3), "
"B<strftime>(3), B<ctime>(3)"
--
Man page: find.1
Issue: The third line is different in current testing as of 2016-08-08 && 2018-04-07

"B<$ find . -name *.c -print>\n"
"find: paths must precede expression\n"
"find: possible unquoted pattern after predicate `-name'?\n"
--
Man page: find.1
Issue: `strftime' -> B<strftime>(3)

"File's last access time in the format specified by I<k>, which is either `@' "
"or a directive for the C `strftime' function.  The following shows an "
"incomplete list of possible values for I<k>.  Please refer to the "
"documentation of `strftime' for the full list.  Some of the conversion "
"specification characters might not be available on all systems, due to "
"differences in the implementation of the `strftime' library function."
msgstr ""
--
Man page: find.1
Issue 1: B</,> -> B</>,
Issue 2: B</.> -> B</>.

"Print the basename; the file's name with any leading directories removed "
"(only the last element).  For B</,> the result is B</.> See the B<EXAMPLES> "
"section for an example."
--
Man page: find.1
Issue: B</,> ), -> B</> ),

"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 B<EXAMPLES> section for an example."

Helge Kreutzmann <kreutzm>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #50589:  fu-patches.tar.gz added by berny (19KiB - application/gzip - [PATCH 00/12] Patch series to improve the man page formatting)
file #50576:  2nd_version_patch.diff added by ametzler (3KiB - text/x-diff - 2nd version of proposed patch, fixing another issue.)
file #50575:  typo.fixes.diff added by ametzler (2KiB - text/x-diff - suggested patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by berny (Updated the item)
  • -email is unavailable- added by kreutzm (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-01-09 berny Open/ClosedOpen Closed
        Fixed ReleaseNone 4.8.0
    2020-12-30 berny StatusCode Review Fixed
    2020-12-30 berny Attached File- Added fu-patches.tar.gz, #50589
        Categoryfind documentation
        StatusNone Code Review
        Assigned toNone berny
    2020-12-27 ametzler Attached File- Added 2nd_version_patch.diff, #50576
    2020-12-27 ametzler Attached File- Added typo.fixes.diff, #50575

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code