[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #59745] Issues in findutils manpages
From: |
Andreas Metzler |
Subject: |
[bug #59745] Issues in findutils manpages |
Date: |
Sun, 27 Dec 2020 03:02:51 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0 |
Follow-up Comment #1, bug #59745 (project findutils):
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
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?59745>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
- [bug #59745] Issues in findutils manpages, Helge Kreutzmann, 2020/12/21
- [bug #59745] Issues in findutils manpages,
Andreas Metzler <=
- [bug #59745] Issues in findutils manpages, Andreas Metzler, 2020/12/27
- [bug #59745] Issues in findutils manpages, Helge Kreutzmann, 2020/12/27
- [bug #59745] Issues in findutils manpages, Andreas Metzler, 2020/12/27
- [bug #59745] Issues in findutils manpages, Andreas Metzler, 2020/12/27
- [bug #59745] Issues in findutils manpages, Helge Kreutzmann, 2020/12/27
- [bug #59745] Issues in findutils manpages, Andreas Metzler, 2020/12/27
- [bug #59745] Issues in findutils manpages, Bernhard Voelker, 2020/12/30
- [bug #59745] Issues in findutils manpages, Andreas Metzler, 2020/12/30
- [bug #59745] Issues in findutils manpages, Helge Kreutzmann, 2020/12/30
- [bug #59745] Issues in findutils manpages, Bernhard Voelker, 2020/12/30