[bug #59745] Issues in findutils manpages

[Helge Kreutzmann]

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

                 Summary: Issues in findutils manpages
                 Project: findutils
            Submitted by: kreutzm
            Submitted on: Mon 21 Dec 2020 03:42:25 PM UTC
                Category: find
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: 4.7.0
         Discussion Lock: Any
           Fixed Release: None

    _______________________________________________________

Details:

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





    _______________________________________________________

Reply to this item at:

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

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