GNU bug report logs - #12365
Incorrect return value of cp with no-clobber option

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 12365 in the body.
You can then email your comments to 12365 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: Anoop Sharma <sendtoanoop <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: Incorrect return value of cp with no-clobber option
Date: Thu, 6 Sep 2012 17:27:52 +0530

When -n (--no-clobber) option of cp is used and the DEST file exists, then, as
expected, cp is not able to copy the SOURCE to DEST.

However, cp returns 0 in this case.

Shouldn't it return 1 to indicate that copy operation could not be completed?

In absence of this indication how is one to know that some recovery
action like re-trying cp with some other DEST name is required?

Regards,
Anoop

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

From: Eric Blake <eblake <at> redhat.com>
To: Anoop Sharma <sendtoanoop <at> gmail.com>
Cc: 12365-done <at> debbugs.gnu.org, coreutils <coreutils <at> gnu.org>
Subject: Re: Should cp -n return 0, when DEST exists?
Date: Thu, 06 Sep 2012 08:31:53 -0600

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

tag 12365 wontfix
thanks

On 09/06/2012 04:50 AM, Anoop Sharma wrote:
> When -n option of cp is used and the DEST file exists, then, as
> expected, cp is not able to copy the SOURCE to DEST.
> 
> However, cp returns 0 in this case.

cp -n is not mandated by POSIX, so we are free to do as we wish here.
But looking at history, we added -n for coreutils 7.1 in Feb 2009, and
the mail from that thread includes:
https://lists.gnu.org/archive/html/bug-coreutils/2008-12/msg00159.html

which states we are modeling after FreeBSD.  A quick check on my FreeBSD
8.2 VM shows:

$ echo one > bar
$ echo two > blah
$ cp -n blah bar
$ echo $?
0
$ cat bar
one

that FreeBSD also returns 0 in this case, and I don't want to break
interoperability.  Therefore, I'm going to close this as a WONTFIX,
unless you also get buy-in from the BSD folks.

By the way, there's no need to post three separate emails with the same
contents, without first waiting at least 24 hours.  Like most other
moderated GNU lists, you do not have to be a subscriber to post, and
even if you are a subscriber, your first post to a given list will be
held in a moderation queue for as long as it takes for a human to
approve your email address as a non-spammer for all future posts
(generally less than a day).

-- 
Eric Blake   eblake <at> redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

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

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Anoop Sharma <sendtoanoop <at> gmail.com>, Eric Blake <eblake <at> redhat.com>
Cc: 12365-done <at> debbugs.gnu.org, coreutils <coreutils <at> gnu.org>
Subject: Re: bug#12365: Should cp -n return 0, when DEST exists?
Date: Thu, 6 Sep 2012 17:21:25 +0200 (CEST)

On September 6, 2012 at 4:31 PM Eric Blake <eblake <at> redhat.com> wrote:

> $ echo one > bar
> $ echo two > blah
> $ cp -n blah bar
> $ echo $?
> 0
> $ cat bar
> one
>
> that FreeBSD also returns 0 in this case, and I don't want to break
> interoperability.  Therefore, I'm going to close this as a WONTFIX,
> unless you also get buy-in from the BSD folks.

Actually -n is implemented as if the user had answered 'n'
when he used the -i option - sure enough without prompting
the user.

  $ echo n | cp -vi blah bar
  cp: overwrite `bar'?
  $ echo $?
  0

BTW: it's similar with the mv command.


The texi page is a bit sparse about the exit value:

  @exitstatus

Maybe it's worth adding a line about the exist status
when using -n or -i (together with answering 'n')?

Have a nice day,
Berny

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

From: Jim Meyering <jim <at> meyering.net>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: Anoop Sharma <sendtoanoop <at> gmail.com>, 12365-done <at> debbugs.gnu.org,
	Eric Blake <eblake <at> redhat.com>, coreutils <coreutils <at> gnu.org>
Subject: Re: bug#12365: Should cp -n return 0, when DEST exists?
Date: Thu, 06 Sep 2012 17:24:02 +0200

Bernhard Voelker wrote:
> On September 6, 2012 at 4:31 PM Eric Blake <eblake <at> redhat.com> wrote:
>
>> $ echo one > bar
>> $ echo two > blah
>> $ cp -n blah bar
>> $ echo $?
>> 0
>> $ cat bar
>> one
>>
>> that FreeBSD also returns 0 in this case, and I don't want to break
>> interoperability.  Therefore, I'm going to close this as a WONTFIX,
>> unless you also get buy-in from the BSD folks.
>
> Actually -n is implemented as if the user had answered 'n'
> when he used the -i option - sure enough without prompting
> the user.
>
>   $ echo n | cp -vi blah bar
>   cp: overwrite `bar'?
>   $ echo $?
>   0
>
> BTW: it's similar with the mv command.
>
>
> The texi page is a bit sparse about the exit value:
>
>   @exitstatus
>
> Maybe it's worth adding a line about the exist status
> when using -n or -i (together with answering 'n')?

Yes, please.  That would be an improvement.

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Jim Meyering <jim <at> meyering.net>
Cc: Anoop Sharma <sendtoanoop <at> gmail.com>, 12365-done <at> debbugs.gnu.org,
	Eric Blake <eblake <at> redhat.com>, coreutils <coreutils <at> gnu.org>
Subject: Re: bug#12365: Should cp -n return 0, when DEST exists?
Date: Thu, 6 Sep 2012 18:52:22 +0200 (CEST)

On September 6, 2012 at 5:24 PM Jim Meyering <jim <at> meyering.net> wrote:

> Bernhard Voelker wrote:
> > Maybe it's worth adding a line about the exist status
> > when using -n or -i (together with answering 'n')?
>
> Yes, please.  That would be an improvement.

(my first patch created on cygwin)


From 65d2d16340cee38f0a7e059af86be49f21eef84d Mon Sep 17 00:00:00 2001
From: Bernhard Voelker <bernhard.voelker <at> siemens-enterprise.com>
Date: Thu, 6 Sep 2012 18:39:47 +0200
Subject: [PATCH] doc: improve documentation of -n and -i for cp and mv
* doc/coreutils.texi (cp invocation): Add a note about to the
description of the option -n how it compares to -i. Add a note
about a possible exit status zero when -n or -i is used.
(mv invocation): Likewise.
---
doc/coreutils.texi | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index f2620bc..0324d1b 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -7772,8 +7772,14 @@ a regular file in the destination tree.
@opindex -n
@opindex --no-clobber
Do not overwrite an existing file. The @option{-n} option overrides a previous
-@option{-i} option. This option is mutually exclusive with @option{-b} or
-@option{--backup} option.
+@option{-i} option.
+@macro optClobberAndI
+In effect, this option works as if the option @option{-i}
+was given and the user declined all questions to overwrite the targets (sure
+enough without prompting).
+@end macro
+@optClobberAndI
+This option is mutually exclusive with @option{-b} or @option{--backup} option.

@item -P
@itemx --no-dereference
@@ -8026,8 +8032,15 @@ However, mount point directories @emph{are} copied.

@end table

+@cindex exit status of @command{cp}
+Exit status:
+
@exitstatus

+However, if the existing target is not overwritten because the option
+@option{-n} is used or the option @option{-i} is used and the user has declined
+overwriting that file, then @command{cp}'s exit status is yet zero.
+

@node dd invocation
@section @command{dd}: Convert and copy a file
@@ -8747,6 +8760,7 @@ If the response is not affirmative, the file is skipped.
@cindex prompts, omitting
Do not overwrite an existing file.
@mvOptsIfn
+@optClobberAndI
This option is mutually exclusive with @option{-b} or @option{--backup} option.

@item -u
@@ -8778,8 +8792,15 @@ Print the name of each file before moving it.

@end table

+@cindex exit status of @command{mv}
+Exit status:
+
@exitstatus

+However, if the existing target is not overwritten because the option
+@option{-n} is used or the option @option{-i} is used and the user has declined
+overwriting that file, then @command{mv}'s exit status is yet zero.
+

@node rm invocation
@section @command{rm}: Remove files or directories
--
1.7.9

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

From: Anoop Sharma <sendtoanoop <at> gmail.com>
To: 12365 <at> debbugs.gnu.org
Subject: Re: bug#12365: closed (Re: Should cp -n return 0, when DEST exists?)
Date: Fri, 7 Sep 2012 11:51:14 +0530

On Thu, Sep 6, 2012 at 8:03 PM, GNU bug Tracking System
<help-debbugs <at> gnu.org> wrote:
> Your bug report
>
> #12365: Incorrect return value of cp with no-clobber option
>
> which was filed against the coreutils package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 12365 <at> debbugs.gnu.org.
>
> --
> 12365: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12365
> GNU Bug Tracking System
> Contact help-debbugs <at> gnu.org with problems
>
>
> ---------- Forwarded message ----------
> From: Eric Blake <eblake <at> redhat.com>
> To: Anoop Sharma <sendtoanoop <at> gmail.com>
> Cc: 12365-done <at> debbugs.gnu.org, coreutils <coreutils <at> gnu.org>
> Date: Thu, 06 Sep 2012 08:31:53 -0600
> Subject: Re: Should cp -n return 0, when DEST exists?
> tag 12365 wontfix
> thanks
>
> On 09/06/2012 04:50 AM, Anoop Sharma wrote:
>> When -n option of cp is used and the DEST file exists, then, as
>> expected, cp is not able to copy the SOURCE to DEST.
>>
>> However, cp returns 0 in this case.
>
> cp -n is not mandated by POSIX, so we are free to do as we wish here.
> But looking at history, we added -n for coreutils 7.1 in Feb 2009, and
> the mail from that thread includes:
> https://lists.gnu.org/archive/html/bug-coreutils/2008-12/msg00159.html
>
> which states we are modeling after FreeBSD.  A quick check on my FreeBSD
> 8.2 VM shows:
>
> $ echo one > bar
> $ echo two > blah
> $ cp -n blah bar
> $ echo $?
> 0
> $ cat bar
> one
>
> that FreeBSD also returns 0 in this case, and I don't want to break
> interoperability.  Therefore, I'm going to close this as a WONTFIX,
> unless you also get buy-in from the BSD folks.
>
> By the way, there's no need to post three separate emails with the same
> contents, without first waiting at least 24 hours.  Like most other
> moderated GNU lists, you do not have to be a subscriber to post, and
> even if you are a subscriber, your first post to a given list will be
> held in a moderation queue for as long as it takes for a human to
> approve your email address as a non-spammer for all future posts
> (generally less than a day).
>
> --
> Eric Blake   eblake <at> redhat.com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
>
> ---------- Forwarded message ----------
> From: Anoop Sharma <sendtoanoop <at> gmail.com>
> To: bug-coreutils <at> gnu.org
> Cc:
> Date: Thu, 6 Sep 2012 17:27:52 +0530
> Subject: Incorrect return value of cp with no-clobber option
> When -n (--no-clobber) option of cp is used and the DEST file exists, then, as
> expected, cp is not able to copy the SOURCE to DEST.
>
> However, cp returns 0 in this case.
>
> Shouldn't it return 1 to indicate that copy operation could not be completed?
>
> In absence of this indication how is one to know that some recovery
> action like re-trying cp with some other DEST name is required?
>
> Regards,
> Anoop
>
>
>


Thank you, Eric.

I am a newbie to open source development tools and processes. I had
posted earlier to bug-coreutils <at> gnu.org and had got an acknowledgement
mail immediately.

Subsequently, I subscribed to coreutils <at> gnu.org and have now been
subscribed for more than a month. I originally posted this mail to
that list for discussion. However, there was no acknowledgement from
there and I mistakenly assumed that some spam filter is stopping my
mails from reaching the list. Therefore, I tweaked the text a bit in
an attempt to get past the spam filter and tried multiple times.
Finally, as a work-around, I posted to bug-coreutils <at> gnu.org and
stopped thereafter, because I got an ack again!

I will be more patient next time!

Thanks for educating,
Anoop

Previous Next

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