GNU bug report logs -
#72914
Issues in man pages of GNU Coreutils
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 72914 in the body.
You can then email your comments to 72914 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org
:
bug#72914
; Package
coreutils
.
(Sat, 31 Aug 2024 11:27:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Helge Kreutzmann <debian <at> helgefjell.de>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Sat, 31 Aug 2024 11:27:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Dear Coreutils maintainer,
the manpage-l10n project maintains a large number of translations of
man pages both from a large variety of sources (including coreutils) 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: chgrp.1
Issue: values → values.
"use RFILE's ownership rather than specifying values RFILE is always "
"dereferenced if a symbolic link."
--
Man page: chgrp.1
Issue: '-P' → B<-P>
"The following options modify how a hierarchy is traversed when the B<-R> "
"option is also specified. If more than one is specified, only the final one "
"takes effect. '-P' is the default."
--
Man page: chmod.1
Issue: '-H' → B<-H>
"The following options modify how a hierarchy is traversed when the B<-R> "
"option is also specified. If more than one is specified, only the final one "
"takes effect. '-H' is the default."
--
Man page: chown.1
Issue: values → values.
"use RFILE's ownership rather than specifying values RFILE is always "
"dereferenced if a symbolic link."
--
Man page: chown.1
Issue: '-P' → B<-P>
"The following options modify how a hierarchy is traversed when the B<-R> "
"option is also specified. If more than one is specified, only the final one "
"takes effect. '-P' is the default."
--
Man page: echo.1
Issue: 'printf' → B<printf>(1)
"Consider using the 'printf' command instead, as it avoids problems when "
"outputting option-like strings."
--
Man page: env.1
Issue: Missing line break before "usage"
"-S/--split-string usage in scripts"
--
Man page: expand.1
Issue: Missing full stop
"use comma separated list of tab positions. The last specified position can "
"be prefixed with '/' to specify a tab size to use after the last explicitly "
"specified tab stop. Also a prefix of '+' can be used to align remaining tab "
"stops relative to the last specified tab stop instead of the first column"
--
Man page: sort.1.po
Issue: "manual" is very vague, this is the manual? Be more precise, e.g. B<name>(1)
"compare according to string numerical value; see manual for which strings "
"are supported"
--
Man page: unexpand.1
Issue: Missing full stop
"use comma separated list of tab positions. The last specified position can "
"be prefixed with '/' to specify a tab size to use after the last explicitly "
"specified tab stop. Also a prefix of '+' can be used to align remaining tab "
"stops relative to the last specified tab stop instead of the first column"
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)]
Reply sent
to
Pádraig Brady <P <at> draigBrady.com>
:
You have taken responsibility.
(Mon, 23 Sep 2024 21:19:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Helge Kreutzmann <debian <at> helgefjell.de>
:
bug acknowledged by developer.
(Mon, 23 Sep 2024 21:19:03 GMT)
Full text and
rfc822 format available.
Message #10 received at 72914-done <at> debbugs.gnu.org (full text, mbox):
On 31/08/2024 12:19, Helge Kreutzmann wrote:
> Dear Coreutils maintainer,
> the manpage-l10n project maintains a large number of translations of
> man pages both from a large variety of sources (including coreutils) 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: chgrp.1
> Issue: values → values.
>
> "use RFILE's ownership rather than specifying values RFILE is always"
> "dereferenced if a symbolic link."
> --
> Man page: chown.1
> Issue: values → values.
>
> "use RFILE's ownership rather than specifying values RFILE is always"
> "dereferenced if a symbolic link."
> --
Above already fixed (but not yet released) in:
https://github.com/coreutils/coreutils/commit/e8c2b921c
> --
> Man page: chgrp.1
> Issue: '-P' → B<-P>
>
> "The following options modify how a hierarchy is traversed when the B<-R>"
> "option is also specified. If more than one is specified, only the final one"
> "takes effect. '-P' is the default."
> --
> Man page: chmod.1
> Issue: '-H' → B<-H>
>
> "The following options modify how a hierarchy is traversed when the B<-R>"
> "option is also specified. If more than one is specified, only the final one"
> "takes effect. '-H' is the default."
> --
> Man page: chown.1
> Issue: '-P' → B<-P>
>
> "The following options modify how a hierarchy is traversed when the B<-R>"
> "option is also specified. If more than one is specified, only the final one"
> "takes effect. '-P' is the default."
Fixed in the just pushed:
https://github.com/coreutils/coreutils/commit/afab48f23
> --
> Man page: echo.1
> Issue: 'printf' → B<printf>(1)
>
> "Consider using the 'printf' command instead, as it avoids problems when"
> "outputting option-like strings."
Fixed in the just pushed:
https://github.com/coreutils/coreutils/commit/7337076ec
> --
> Man page: env.1
> Issue: Missing line break before "usage"
>
> "-S/--split-string usage in scripts"
I think this is OK, however,
the confusion probably stems from the section header [OPTIONS].
I've adjusted this to the more descriptive: [SCRIPT OPTION HANDLING],
and also removed some overly detailed info from the man page.
https://github.com/coreutils/coreutils/commit/4da7daa01
> --
> Man page: expand.1
> Issue: Missing full stop
>
> "use comma separated list of tab positions. The last specified position can"
> "be prefixed with '/' to specify a tab size to use after the last explicitly"
> "specified tab stop. Also a prefix of '+' can be used to align remaining tab"
> "stops relative to the last specified tab stop instead of the first column"
> --
> Man page: unexpand.1
> Issue: Missing full stop
>
> "use comma separated list of tab positions. The last specified position can"
> "be prefixed with '/' to specify a tab size to use after the last explicitly"
> "specified tab stop. Also a prefix of '+' can be used to align remaining tab"
> "stops relative to the last specified tab stop instead of the first column"
These follows the pattern of the last sentence in an option description
_not_ having a full stop. There were a few cases where we weren't
consistent with that pattern actually, which are now fixed up in:
https://github.com/coreutils/coreutils/commit/ac5213acb
> --
> Man page: sort.1.po
> Issue: "manual" is very vague, this is the manual? Be more precise, e.g. B<name>(1)
>
> "compare according to string numerical value; see manual for which strings"
> "are supported"
Fixed in the just pushed:
https://github.com/coreutils/coreutils/commit/9e5274cd1be
Marking this as done.
Many thanks!
Pádraig.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 22 Oct 2024 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 236 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.