GNU bug report logs - #18681
The Linux cp command has bugs

Previous Next

Full log

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

From: Bob Proulx <bob <at> proulx.com>
To: "Polehn, Mike A" <mike.a.polehn <at> intel.com>,
 Assaf Gordon <assafgordon <at> gmail.com>,
 "18681 <at> debbugs.gnu.org" <18681 <at> debbugs.gnu.org>
Subject: Re: bug#18681: The Linux cp command has bugs
Date: Sun, 19 Oct 2014 18:04:17 -0600

close 18681
thanks

Eric Blake wrote:
> Polehn, Mike A wrote:
> > This still left the incorrect operation of the interactive
> > operation when both -i and -f is used.
> 
> The behavior of -i vs. -f interaction is required by POSIX; in
> particular, POSIX is explicit that -i and -f are NOT a toggle switch of
> one another, but each turns on slightly different, somewhat overlapping,
> changes in behavior (so specifying both is different from specifying one
> in isolation).  We can't change what either one of those flags means.

This bug log included some serious topic drift of which I contributed
to myself.  In order to atone for that I am going to triage this as
saying that the behavior is intended and standardized and therefore
won't be changed.  Now that we understand this the bug ticket can be
closed.  Further discussion can be continued and it will all be logged
and read by the subscribed.

> If there is another mode of operation that is also useful, then it needs
> yet another flag.  At one point in the past, we had
> --reply={yes,no,query} to try and offer a third mode, but it had
> confusing semantics and we ended up pulling it because of the confusion
> it could cause.  At the time we pulled it, we admitted that 'rsync' has
> some modes of operations that might be better suited for the particular
> modes that people people seemed to be requesting when they thought that
> --reply would do the trick (and usually, what they thought --reply would
> do and what it actually did were different, which is why we removed it
> to avoid confusion).  We have also added a --no-clobber option, which is
> somewhat of a compromise (what some people thought --reply=no would do,
> --no-clobber actually does better).

Good summary!

> So adding a new option is not out of the question, but you'd have to
> have well-defined semantics of what it should do, and how it differs
> from either normal mode, '-i' mode, '-f' mode, '-i -f' mode, or
> '--no-clobber' mode.

If the readers of this ticket think there is an enhancement request to
be filed for cp then please file a wishlist bug with the proposal.  A
reference to this log can be made if desired.  Let me suggest that the
proposal first be made on the coreutils discussion list where it can
be discussed and shaped and then after that has been done file a
wishlist bug of the result in order to track its progress through the
code and release.

Bob

Previous Next

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