GNU bug report logs -
#29315
info cp: documentation feedback
Previous Next
Reported by: kalle <kalle <at> projektwerkstatt.de>
Date: Thu, 16 Nov 2017 10:37:02 UTC
Severity: normal
Done: Pádraig Brady <P <at> draigBrady.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29315 in the body.
You can then email your comments to 29315 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#29315
; Package
coreutils
.
(Thu, 16 Nov 2017 10:37:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
kalle <kalle <at> projektwerkstatt.de>
:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org
.
(Thu, 16 Nov 2017 10:37:04 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
hello,
here some mistakes/improvement proposals to `info cp' from me:
-sentence "If the `--target": take away "failing that"?
-sentence "descending into source directories": shouldn't it be rather
"descending into SOURCE's directories"?And since `-r' and `-R' is the
same: write "-r/-R" instead.
-option `-f': why is it written about _opening_ a file, e.g. "opened for
writing" and not simply "writeable"? What is meant by "removes it and
tries to open it again"? It is said "`cp' then removes it". It should be
added ", if the user has write-permission in the containing directory."
-part "-i": shouldn't be written "When copying to a file" instead?
greetings,
kalle
Reply sent
to
Pádraig Brady <P <at> draigBrady.com>
:
You have taken responsibility.
(Sun, 10 Dec 2017 00:24:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
kalle <kalle <at> projektwerkstatt.de>
:
bug acknowledged by developer.
(Sun, 10 Dec 2017 00:24:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 29315-done <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 16/11/17 03:36, kalle wrote:
> hello,
> here some mistakes/improvement proposals to `info cp' from me:
>
> -sentence "If the `--target": take away "failing that"?
It's better as is, to document that these are separate modes
> -sentence "descending into source directories": shouldn't it be rather
> "descending into SOURCE's directories"?
That could be interpreted as only descending one level
> And since `-r' and `-R' is the
> same: write "-r/-R" instead.
That would be less standard/searchable
> -option `-f': why is it written about _opening_ a file, e.g. "opened for
> writing" and not simply "writeable"?
There can be differing restrictions on various operations,
so we're being explicit about the truncation permission.
> What is meant by "removes it and
> tries to open it again"?
It creates a new file rather than rewriting an existing one.
I suppose that could be clarified. Patch attached.
> It is said "`cp' then removes it". It should be
> added ", if the user has write-permission in the containing directory."
There are other permissions that may block the unlink also.
It's better not to partially list potential issues,
and just state what cp does.
> -part "-i": shouldn't be written "When copying to a file" instead?
Subtly no, because we prompt if overwriting a dir with a file.
So the prompt depends on the source, not the dest.
cheers,
Pádraig.
[cp-f-recreate.patch (text/x-patch, attachment)]
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sun, 07 Jan 2018 12:24:04 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
kalle <kalle <at> projektwerkstatt.de>
to
control <at> debbugs.gnu.org
.
(Thu, 16 Aug 2018 19:39:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org
:
bug#29315
; Package
coreutils
.
(Thu, 16 Aug 2018 22:09:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 29315 <at> debbugs.gnu.org (full text, mbox):
I already sent this mail on 19.05.2018, but since I got no response and
my bug-report then had be closed and I just unarchived and reopened it,
here again my message.
> Am 10.12.2017 um 01:23 schrieb Pádraig Brady:
>> On 16/11/17 03:36, kalle wrote:
>> here some mistakes/improvement proposals to `info cp' from me:
>> -sentence "If the `--target": take away "failing that"?
>
> It's better as is, to document that these are separate modes
I simply don't understand the sentence. what is meant by
"If the ‘--target-directory’ (‘-t’) option is given, or failing that
if the last file is a directory and the ‘--no-target-directory’
(‘-T’) option is not given " ?
-the sentence "just as they are read" sounds ambiguous using the words
"just as", since it is not clear if it refers to a time point or to an
operating mode..
That it is not about a time point becomes clear from the reference to
the 'sparse'-option, but it shouldn't be necessary to read information
about the sparse-option first to understand this sentence.
-option "sparse": I don't really understand the explanation - do the
'holes' neither contain any physical device blocks nor any space at all?
Then - how is this possible How can a series of zero bytes not occupy
any physical disk blocks?
>> -sentence "descending into source directories": shouldn't it be rather
>> "descending into SOURCE's directories"?
>
> That could be interpreted as only descending one level
I don't understand why only the first level of subdirectories could be
meant, but that point is not so important to me.
>
>> And since `-r' and `-R' is the
>> same: write "-r/-R" instead.
>
> That would be less standard/searchable
what I meant was, to write "-r/-R" in the sentence "to copy recursively
by descending".
>
>> -option `-f': why is it written about _opening_ a file, e.g. "opened for
>> writing" and not simply "writeable"?
>
> There can be differing restrictions on various operations,
> so we're being explicit about the truncation permission.
maybe one could add a specific, more common example of such a
restriction situation or refer to further explanation such that the
terminology (writing a file) seems not too alienating, as it was to me.
kalle
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 14 Sep 2018 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 197 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.