GNU bug report logs - #29315
info cp: documentation feedback

Previous Next

Package: coreutils;

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.

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: kalle <kalle <at> projektwerkstatt.de>
To: bug-coreutils <at> gnu.org
Subject: info cp: documentation feedback
Date: Thu, 16 Nov 2017 12:36:06 +0100
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):

From: Pádraig Brady <P <at> draigBrady.com>
To: kalle <kalle <at> projektwerkstatt.de>, 29315-done <at> debbugs.gnu.org
Subject: Re: bug#29315: info cp: documentation feedback
Date: Sat, 9 Dec 2017 16:23:24 -0800
[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):

From: kalle <kalle <at> projektwerkstatt.de>
To: Pádraig Brady <P <at> draigBrady.com>, 29315 <at> debbugs.gnu.org
Subject: Re: bug#29315: info cp: documentation feedback
Date: Fri, 17 Aug 2018 00:08:43 +0200
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.