GNU bug report logs - #45353
Errors in man pages

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45353 in the body.
You can then email your comments to 45353 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helge Kreutzmann <debian <at> helgefjell.de>
To: bug-grep <at> gnu.org
Subject: Errors in man pages
Date: Mon, 21 Dec 2020 17:11:29 +0100

[Message part 1 (text/plain, inline)]

Dear grep maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including grep) 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: grep.1
Issue: The option was mentioned above!

"Suppress normal output; instead print a count of matching lines for each "
"input file.  With the B<-v>, B<-\\^-invert-match> option (see below), count "
"non-matching lines."
--
Man page: grep.1
Issue: Reorder text?

"Report Unix-style byte offsets.  This switch causes B<grep> to report byte "
"offsets as if the file were a Unix-style text file, i.e., with CR characters "
"stripped off.  This will produce results identical to running B<grep> on a "
"Unix machine.  This option has no effect unless B<-b> option is also used; "
"it has no effect on platforms other than MS-DOS and MS-Windows."
--
Man page: grep.1
Issue 1: pcresyntax(3) → B<pcresyntax>(3)
Issue 2: pcrepattern(3) → B<pcrepattern>(3)

"B<grep> understands three different versions of regular expression syntax: "
"``basic'' (BRE), ``extended'' (ERE) and ``perl'' (PCRE).  In GNU B<grep> "
"there is no difference in available functionality between basic and extended "
"syntaxes.  In other implementations, basic regular expressions are less "
"powerful.  The following description applies to extended regular "
"expressions; differences for basic regular expressions are summarized "
"afterwards.  Perl-compatible regular expressions give additional "
"functionality, and are documented in pcresyntax(3) and pcrepattern(3), but "
"work only if PCRE is available in the system."
--
Man page: grep.1
Issue: Order of entrie not according to man-pages(7)

"B<awk>(1), B<cmp>(1), B<diff>(1), B<find>(1), B<perl>(1), B<sed>(1), "
"B<sort>(1), B<xargs>(1), B<read>(2), B<pcre>(3), B<pcresyntax>(3), "
"B<pcrepattern>(3), B<terminfo>(5), B<glob>(7), B<regex>(7)."
--
Man page: grep.1
Issue: PATTERNS → I<PATTERNS>

"Interpret PATTERNS as Perl-compatible regular expressions (PCREs).  This "
"option is experimental when combined with the B<-z> (B<-\\^-null-data>)  "
"option, and B<grep -P> may warn of unimplemented features."
--
Man page: grep.1
Issue: Not in "grep --help"; remove?

"B<-y>"
--
Man page: grep.1
Issue: Not in --help; is it a valid option?

"B<-u>, B<-\\^-unix-byte-offsets>"
--
Man page: grep.1
Issue: grep should be in B<>

"Read all files under each directory, recursively, following symbolic links "
"only if they are on the command line.  Note that if no file operand is "
"given, grep searches the working directory.  This is equivalent to the B<-d "
"recurse> option."

-- 
      Dr. Helge Kreutzmann                     debian <at> helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 45353 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Helge Kreutzmann <debian <at> helgefjell.de>
Cc: 45353 <at> debbugs.gnu.org
Subject: Re: bug#45353: Errors in man pages
Date: Wed, 23 Dec 2020 08:46:05 -0800

[Message part 1 (text/plain, inline)]

On Mon, Dec 21, 2020 at 8:12 AM Helge Kreutzmann <debian <at> helgefjell.de> wrote:
...

Thank you for the suggestions.

> Man page: grep.1
> Issue: The option was mentioned above!
>
> "Suppress normal output; instead print a count of matching lines for each "
> "input file.  With the B<-v>, B<-\\^-invert-match> option (see below), count "
> "non-matching lines."

That is expected. Its primary description is above.
This part tells how it works when combined with the -c option.

> --
> Man page: grep.1
> Issue: Reorder text?
>
> "Report Unix-style byte offsets.  This switch causes B<grep> to report byte "
> "offsets as if the file were a Unix-style text file, i.e., with CR characters "
> "stripped off.  This will produce results identical to running B<grep> on a "
> "Unix machine.  This option has no effect unless B<-b> option is also used; "
> "it has no effect on platforms other than MS-DOS and MS-Windows."

As mentioned below, this entire option (-u) is about to disappear.

> --
> Man page: grep.1
> Issue 1: pcresyntax(3) → B<pcresyntax>(3)
> Issue 2: pcrepattern(3) → B<pcrepattern>(3)
>
> "B<grep> understands three different versions of regular expression syntax: "
> "``basic'' (BRE), ``extended'' (ERE) and ``perl'' (PCRE).  In GNU B<grep> "
> "there is no difference in available functionality between basic and extended "
> "syntaxes.  In other implementations, basic regular expressions are less "
> "powerful.  The following description applies to extended regular "
> "expressions; differences for basic regular expressions are summarized "
> "afterwards.  Perl-compatible regular expressions give additional "
> "functionality, and are documented in pcresyntax(3) and pcrepattern(3), but "
> "work only if PCRE is available in the system."

Done.

> --
> Man page: grep.1
> Issue: Order of entrie not according to man-pages(7)
>
> "B<awk>(1), B<cmp>(1), B<diff>(1), B<find>(1), B<perl>(1), B<sed>(1), "
> "B<sort>(1), B<xargs>(1), B<read>(2), B<pcre>(3), B<pcresyntax>(3), "
> "B<pcrepattern>(3), B<terminfo>(5), B<glob>(7), B<regex>(7)."

I read man-pages(7)'s section on SEE ALSO and found only one nit here.
It terminated the list with a period, while man-pages(7) says to
provide no period.

> The list should be ordered by section number and then alphabetically by name.  Do not terminate this list with a period.

If there's something else, please be more precise.

Actually, for each suggestion in the future, please provide an actual
diff. That would be far better.

> --
> Man page: grep.1
> Issue: PATTERNS → I<PATTERNS>
>
> "Interpret PATTERNS as Perl-compatible regular expressions (PCREs).  This "
> "option is experimental when combined with the B<-z> (B<-\\^-null-data>)  "
> "option, and B<grep -P> may warn of unimplemented features."
> --
> Man page: grep.1
> Issue: Not in "grep --help"; remove?
>
> "B<-y>"

This is deliberate. Undocumenting is a necessary step prior to removal
of legacy options like this:

  $ git grep -e -y doc|tail -1
  doc/grep.texi:@option{-y} is an obsolete synonym that is provided
for compatibility.

> --
> Man page: grep.1
> Issue: Not in --help; is it a valid option?
>
> "B<-u>, B<-\\^-unix-byte-offsets>"

Similarly,
      case 'u':
        /* Obsolete option; it has no effect.  FIXME: Diagnose use of
           this option starting in (say) the year 2020.  */
        break;

I'm doing as that suggests in a separate commit.

> --
> Man page: grep.1
> Issue: grep should be in B<>
>
> "Read all files under each directory, recursively, following symbolic links "
> "only if they are on the command line.  Note that if no file operand is "
> "given, grep searches the working directory.  This is equivalent to the B<-d "
> "recurse> option."

Done.

I wrote the attached patch in your name.
Let me know if there's anything else to be done here.

[0001-doc-adjust-man-page-syntax.patch (application/octet-stream, attachment)]

Message #11 received at 45353 <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Helge Kreutzmann <debian <at> helgefjell.de>
Cc: 45353 <at> debbugs.gnu.org
Subject: Re: bug#45353: Errors in man pages
Date: Wed, 23 Dec 2020 09:14:20 -0800

[Message part 1 (text/plain, inline)]

On Wed, Dec 23, 2020 at 8:46 AM Jim Meyering <jim <at> meyering.net> wrote:
>
> On Mon, Dec 21, 2020 at 8:12 AM Helge Kreutzmann <debian <at> helgefjell.de> wrote:
> ...
>
> Thank you for the suggestions.
>
> > Man page: grep.1
> > Issue: The option was mentioned above!
> >
> > "Suppress normal output; instead print a count of matching lines for each "
> > "input file.  With the B<-v>, B<-\\^-invert-match> option (see below), count "
> > "non-matching lines."
>
> That is expected. Its primary description is above.
> This part tells how it works when combined with the -c option.
>
> > --
> > Man page: grep.1
> > Issue: Reorder text?
> >
> > "Report Unix-style byte offsets.  This switch causes B<grep> to report byte "
> > "offsets as if the file were a Unix-style text file, i.e., with CR characters "
> > "stripped off.  This will produce results identical to running B<grep> on a "
> > "Unix machine.  This option has no effect unless B<-b> option is also used; "
> > "it has no effect on platforms other than MS-DOS and MS-Windows."
>
> As mentioned below, this entire option (-u) is about to disappear.
>
> > --
> > Man page: grep.1
> > Issue 1: pcresyntax(3) → B<pcresyntax>(3)
> > Issue 2: pcrepattern(3) → B<pcrepattern>(3)
> >
> > "B<grep> understands three different versions of regular expression syntax: "
> > "``basic'' (BRE), ``extended'' (ERE) and ``perl'' (PCRE).  In GNU B<grep> "
> > "there is no difference in available functionality between basic and extended "
> > "syntaxes.  In other implementations, basic regular expressions are less "
> > "powerful.  The following description applies to extended regular "
> > "expressions; differences for basic regular expressions are summarized "
> > "afterwards.  Perl-compatible regular expressions give additional "
> > "functionality, and are documented in pcresyntax(3) and pcrepattern(3), but "
> > "work only if PCRE is available in the system."
>
> Done.
>
> > --
> > Man page: grep.1
> > Issue: Order of entrie not according to man-pages(7)
> >
> > "B<awk>(1), B<cmp>(1), B<diff>(1), B<find>(1), B<perl>(1), B<sed>(1), "
> > "B<sort>(1), B<xargs>(1), B<read>(2), B<pcre>(3), B<pcresyntax>(3), "
> > "B<pcrepattern>(3), B<terminfo>(5), B<glob>(7), B<regex>(7)."
>
> I read man-pages(7)'s section on SEE ALSO and found only one nit here.
> It terminated the list with a period, while man-pages(7) says to
> provide no period.
>
> > The list should be ordered by section number and then alphabetically by name.  Do not terminate this list with a period.
>
> If there's something else, please be more precise.
>
> Actually, for each suggestion in the future, please provide an actual
> diff. That would be far better.
>
> > --
> > Man page: grep.1
> > Issue: PATTERNS → I<PATTERNS>
> >
> > "Interpret PATTERNS as Perl-compatible regular expressions (PCREs).  This "
> > "option is experimental when combined with the B<-z> (B<-\\^-null-data>)  "
> > "option, and B<grep -P> may warn of unimplemented features."

Oops. Nearly missed this.
I've done this, too.
New patch attached.

...
>
> I wrote the attached patch in your name.
> Let me know if there's anything else to be done here.

[0001-doc-adjust-man-page-syntax.patch (application/octet-stream, attachment)]

Message #14 received at 45353 <at> debbugs.gnu.org (full text, mbox):

From: Helge Kreutzmann <debian <at> helgefjell.de>
To: Jim Meyering <jim <at> meyering.net>
Cc: 45353 <at> debbugs.gnu.org
Subject: Re: bug#45353: Errors in man pages
Date: Wed, 23 Dec 2020 19:03:02 +0100

[Message part 1 (text/plain, inline)]

Hello Jim,
On Wed, Dec 23, 2020 at 09:14:20AM -0800, Jim Meyering wrote:
> On Wed, Dec 23, 2020 at 8:46 AM Jim Meyering <jim <at> meyering.net> wrote:
> > On Mon, Dec 21, 2020 at 8:12 AM Helge Kreutzmann <debian <at> helgefjell.de> wrote:
> > Thank you for the suggestions.

You are welcome. Thanks for handling them this quickly.

I'm only citing parts where necessary, not those where no question or
disagreement is raised. Where applicable, I denote that in our
translated files so the translators in question are aware of your
rationales.

> > > --
> > > Man page: grep.1
> > > Issue: Order of entrie not according to man-pages(7)
> > >
> > > "B<awk>(1), B<cmp>(1), B<diff>(1), B<find>(1), B<perl>(1), B<sed>(1), "
> > > "B<sort>(1), B<xargs>(1), B<read>(2), B<pcre>(3), B<pcresyntax>(3), "
> > > "B<pcrepattern>(3), B<terminfo>(5), B<glob>(7), B<regex>(7)."
> >
> > I read man-pages(7)'s section on SEE ALSO and found only one nit here.
> > It terminated the list with a period, while man-pages(7) says to
> > provide no period.
> >
> > > The list should be ordered by section number and then alphabetically by name.  Do not terminate this list with a period.
> >
> > If there's something else, please be more precise.

This is a nit pick by some translators. I suggest to ignore this
particular issue (I personally don't share their views anymore), I
will mark it WONTFIX in our files.

> > Actually, for each suggestion in the future, please provide an actual
> > diff. That would be far better.

As stated in the introductory text that's unfortunatly not possible.
manpages-l10n has over 100 upstreams an we do not have the man power
to provide full diffs, sorry. (And sometimes we only see that's
something is strange, but do not know how it should be).

However, do not hesitate to ask in any unclear case (when I have not 
been precise enough, despite best efforts). If in doubt I'll double
check with the original translator as well.

> > I wrote the attached patch in your name.
> > Let me know if there's anything else to be done here.

I'm fine if you put my name in there. If possible it would be fair if
you could denote (in a comment of commit message) that the input came
from several members of the manpage-l10n translation community.

Greetings

              Helge

-- 
      Dr. Helge Kreutzmann                     debian <at> helgefjell.de
           Dipl.-Phys.                   http://www.helgefjell.de/debian.php
        64bit GNU powered                     gpg signed mail preferred
           Help keep free software "libre": http://www.ffii.de/

[signature.asc (application/pgp-signature, inline)]

Message #19 received at 45353-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Helge Kreutzmann <debian <at> helgefjell.de>
Cc: 45353-done <at> debbugs.gnu.org
Subject: Re: bug#45353: Errors in man pages
Date: Wed, 23 Dec 2020 10:47:41 -0800

On Wed, Dec 23, 2020 at 10:03 AM Helge Kreutzmann <debian <at> helgefjell.de> wrote:
>
> Hello Jim,
> On Wed, Dec 23, 2020 at 09:14:20AM -0800, Jim Meyering wrote:
> > On Wed, Dec 23, 2020 at 8:46 AM Jim Meyering <jim <at> meyering.net> wrote:
> > > On Mon, Dec 21, 2020 at 8:12 AM Helge Kreutzmann <debian <at> helgefjell.de> wrote:
> > > Thank you for the suggestions.
>
> You are welcome. Thanks for handling them this quickly.
>
> I'm only citing parts where necessary, not those where no question or
> disagreement is raised. Where applicable, I denote that in our
> translated files so the translators in question are aware of your
> rationales.

+1

...
>
> I'm fine if you put my name in there. If possible it would be fair if
> you could denote (in a comment of commit message) that the input came
> from several members of the manpage-l10n translation community.

Done and pushed. See this:
https://git.savannah.gnu.org/cgit/grep.git/commit/?id=91ce9cdad384cb6d774e9884707c7f00946d909d

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.