GNU bug report logs -
#53946
Errors 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 53946 in the body.
You can then email your comments to 53946 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#53946; Package
coreutils.
(Sat, 12 Feb 2022 05:58:01 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, 12 Feb 2022 05:58:01 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: arch.1
Issue: missing markup (B<>)
"uname(1), uname(2)"
--
Man page: b2sum.1
Issue: missing markup (B<>)
"cksum(1)"
--
Man page: basename.1
Issue: missing markup (B<>)
"dirname(1), readlink(1)"
--
Man page: chgrp.1
Issue: missing markup (B<>)
"chown(1), chown(2)"
--
Man page: chmod.1
Issue: missing markup (B<>)
"chmod(2)"
--
Man page: chown.1
Issue: missing markup (B<>)
"chown(2)"
--
Man page: chroot.1
Issue: missing markup (B<>)
"chroot(2)"
--
Man page: chroot.8
Issue: missing markup (B<>)
"chroot(2)"
--
Man page: comm.1
Issue: missing markup (B<>)
Issue: "join(1), uniq(1)"
--
Man page: dirname.1
Issue: missing markup (B<>)
"basename(1), readlink(1)"
--
Man page: env.1
Issue: missing markup (B<>)
"sigaction(2), sigprocmask(2), signal(7)"
--
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: expand.1
Issue: missing markup (B<>)
"unexpand(1)"
--
Man page: head.1
Issue: missing markup (B<>)
"tail(1)"
--
Man page: hostid.1
Issue: missing markup (B<>)
"gethostid(3)"
--
Man page: join.1
Issue: missing markup (B<>)
"comm(1), uniq(1)"
--
Man page: link.1
Issue: missing markup (B<>)
"link(2)"
--
Man page: ln.1
Issue: missing markup (B<>)
"link(2), symlink(2)"
--
Man page: ls.1
Issue: seems to be an unnecessary split of paragraphs; join with next one
"can be augmented with a B<--sort> option, but any use of B<--sort>=I<\\,none"
"\\/> (B<-U>) disables grouping"
--
Man page: ls.1
Issue: seems to be an unnecessary split of paragraphs; join with next one
msgid "that points to a directory"
--
Man page: ls.1
Issue 1: LS_COLORS → B<LS_COLORS>
Issue 2: dircolors → B<dircolors>(1)
"Using color to distinguish file types is disabled both by default and with "
"B<--color>=I<\\,never\\/>. With B<--color>=I<\\,auto\\/>, ls emits color "
"codes only when standard output is connected to a terminal. The LS_COLORS "
"environment variable can change the settings. Use the dircolors command to "
"set it."
--
Man page: md5sum.1
Issue: missing markup (B<>)
"cksum(1)"
--
Man page: mkdir.1
Issue: missing markup (B<>)
"mkdir(2)"
--
Man page: mkfifo.1
Issue: missing markup (B<>)
"mkfifo(3)"
--
Man page: mknod.1
Issue: missing markup (B<>)
"mknod(2)"
--
Man page: mv.1
Issue: missing markup (B<>)
"rename(2)"
--
Man page: nice.1
Issue: missing markup (B<>)
"nice(2), renice(1)"
--
Man page: printf.1
Issue: missing markup (B<>)
"printf(3)"
--
Man page: pwd.1
Issue: missing markup (B<>)
"getcwd(3)"
--
Man page: readlink.1
Issue: missing markup (B<>)
"readlink(2), realpath(1), realpath(3)"
--
Man page: realpath.1
Issue: missing markup (B<>)
"readlink(1), readlink(2), realpath(3)"
--
Man page: realpath.1
Issue: shred(1) → B<shred>(1)
"Note that if you use rm to remove a file, it might be possible to recover "
"some of its contents, given sufficient expertise and/or time. For greater "
"assurance that the contents are truly unrecoverable, consider using shred(1)."
--
Man page: realpath.1
Issue: missing markup (B<>)
"unlink(1), unlink(2), chattr(1), shred(1)"
--
Man page: rmdir.1
Issue: missing markup (B<>)
"rmdir(2)"
--
Man page: rmdir.1
Issue: missing markup (B<>)
msgid ""
--
Man page: rmdir.1
Issue: join this string with the next one "is non-empty"
"ignore each failure that is solely because a directory"
--
Man page: sha1sum.1
Issue: missing markup (B<>)
"cksum(1)"
--
Man page: sha224sum.1
Issue: missing markup (B<>)
"cksum(1)"
--
Man page: sha256sum.1
Issue: missing markup (B<>)
"cksum(1)"
--
Man page: sha384sum.1
Issue: missing markup (B<>)
"cksum(1)"
--
Man page: sha512sum.1
Issue: missing markup (B<>)
"cksum(1)"
--
Man page: sleep.1
Issue: missing markup (B<>)
"sleep(3)"
--
Man page: sort.1
Issue: missing markup (B<>)
"shuf(1), uniq(1)"
--
Man page: stat.1
Issue: missing markup (B<>)
"stat(2), statfs(2), statx(2)"
--
Man page: sync.1
Issue: missing markup (B<>)
"fdatasync(2), fsync(2), sync(2), syncfs(2)"
--
Man page: tail.1
Issue: missing markup (B<>)
msgid "head(1)"
--
Man page: test.1
Issue: [ → test
"Full documentation E<lt>https://www.gnu.org/software/coreutils/[E<gt>"
--
Man page: timeout.1
Issue: missing markup (B<>)
"kill(1)"
--
Man page: truncate.1
Issue: missing markup (B<>)
"dd(1), truncate(2), ftruncate(2)"
--
Man page: uname.1
Issue: missing markup (B<>)
"arch(1), uname(2)"
--
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"
--
Man page: unexpand.1
Issue: missing markup (B<>)
"expand(1)"
--
Man page: uniq.1
Issue: missing markup (B<>)
"comm(1), join(1), sort(1)"
--
Man page: users.1
Issue: missing markup (B<>)
"getent(1), who(1)"
--
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.
(Sat, 12 Feb 2022 18:51:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Helge Kreutzmann <debian <at> helgefjell.de>:
bug acknowledged by developer.
(Sat, 12 Feb 2022 18:51:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 53946-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 12/02/2022 05:57, 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: arch.1
> Issue: missing markup (B<>)
>
> "uname(1), uname(2)"
I'm not sure about marking up references like this.
There should be enough context from the reference
for the man page reader to display appropriately.
For e.g. I use vim to display man pages, and references
like this are highlighted, and can be followed.
Also looking at other projects, I don't see explicitly
highlighted referenced man pages.
> Man page: expand.1
> Issue: Missing full stop
>
> "use comma separated list of tab positions The last specified position can"
Already fixed upstream.
> Man page: ls.1
> Issue: seems to be an unnecessary split of paragraphs; join with next one
>
> "can be augmented with a B<--sort> option, but any use of B<--sort>=I<\\,none"
> "\\/> (B<-U>) disables grouping"
> --
> Man page: ls.1
> Issue: seems to be an unnecessary split of paragraphs; join with next one
>
> msgid "that points to a directory"
> --
Yes good point.
The issue here is those newlines are generated due to inconsistent indentation.
Attached is a patch to ls to make the indentation consistent.
> Man page: ls.1
> Issue 1: LS_COLORS → B<LS_COLORS>
There are other env vars mentioned.
I'm not sure why this one, or any should be highlighted.
> Issue 2: dircolors → B<dircolors>(1)
Good point re the (1). Added in second patch.
> Man page: rmdir.1
> Issue: join this string with the next one "is non-empty"
>
> "ignore each failure that is solely because a directory"
Added in third patch.
I also noticed an erroneous blank line added in the man page
after the first option. I adjusted the column of the description
to 21 to avoid that, and in a further (4th) patch I adjusted
the description column of --help and --version is all commands
to use column 21 also.
> Man page: test.1
> Issue: [ → test
>
> "Full documentation E<lt>https://www.gnu.org/software/coreutils/[E<gt>"
This is subtle. The link above (with [) does actually work.
Though I notice it's not highlighted appropriately by gnome-terminal
at least, so would be better to use "test" instead.
This is done in patch 5.
> Man page: unexpand.1
> Issue: Missing full stop
>
> "use comma separated list of tab positions The last specified position can"
Already fixed upstream.
Marking this as done.
cheers,
Pádraig
[0005-doc-avoid-using-is-URLS-in-help-output.patch (text/x-patch, attachment)]
[0004-doc-adust-help-version-alignment.patch (text/x-patch, attachment)]
[0003-doc-rmdir-improve-help-formatting.patch (text/x-patch, attachment)]
[0002-doc-ls-reference-dircolors-1-from-help.patch (text/x-patch, attachment)]
[0001-doc-ls-improve-help-formatting.patch (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#53946; Package
coreutils.
(Sat, 12 Feb 2022 19:55:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 53946-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello Pádraig,
thanks for your swift handling.
On Sat, Feb 12, 2022 at 06:50:48PM +0000, Pádraig Brady wrote:
> On 12/02/2022 05:57, Helge Kreutzmann wrote:
> > Man page: arch.1
> > Issue: missing markup (B<>)
> >
> > "uname(1), uname(2)"
>
> I'm not sure about marking up references like this.
> There should be enough context from the reference
> for the man page reader to display appropriately.
> For e.g. I use vim to display man pages, and references
> like this are highlighted, and can be followed.
> Also looking at other projects, I don't see explicitly
> highlighted referenced man pages.
Well, the roundabout 100 projects we have as upstreams in
manpages-l10n do this consistently, e.g. "man man" you can see that
those links are always:
B<name>(1)
Of course, if coreutils differs here, I will mark those "wontfix" and
won't bother you with them any more, of course.
> > Man page: ls.1
> > Issue 1: LS_COLORS → B<LS_COLORS>
>
> There are other env vars mentioned.
> I'm not sure why this one, or any should be highlighted.
Again, we see this in many man pages. Translators did not search for
all occurences, so there is no completness guarantee. Again, if you
decide to use a different convention, those will be FONTFIXE in the
future.
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)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 13 Mar 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 3 years and 151 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.