[bug #59745] Issues in findutils manpages

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

On 2020-12-21 Helge Kreutzmann <[email protected]> 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

    _______________________________________________________

Reply to this item at:

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

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