bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] make "cp -i -f" behaves like "cp -f" instead of like "cp -i"


From: Eric Blake
Subject: Re: [PATCH] make "cp -i -f" behaves like "cp -f" instead of like "cp -i"
Date: Thu, 31 Aug 2006 07:03:56 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060719 Thunderbird/1.5.0.5 Mnenhy/0.7.4.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The mailing list is probably a better place for this discussion than
cc'ing lots of individuals.  I'm adding bug-coreutils accordingly.

According to Thierry Vignaud on 8/31/2006 6:36 AM:
> address@hidden (Eric Blake) writes:
> 
>>> The following patch makes now "cp -i -f" behaves like "cp -f"
>>> instead of like "cp -i".
>>>
>>> We think that behavior is what end users would predict.
>> Thanks for the effort, but POSIX requires the current behavior:
>> http://www.opengroup.org/onlinepubs/009695399/nframe.html especially
>> step 3a, where -i must be handled before -f.
> 
> humm.
> 
> The problem is that:
> - one could expect -i to "win" in 'cp -f -i' and -f to win in 'cp -i -f'
> - if a distro define a default alias 'cp -i' for cp in order to
>   prevent users to shoot themselves in the foot, it's nice to be able
>   to overwrite it.

The user can undo what the distro did, either in their startup scripts, or
with the one-shot \cp.

> 
> I may be misreading but I've read
> http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html and I
> don't see anything that .

"3. If source_file is of type regular file, the following steps shall be
taken:
   a. If dest_file exists, the following steps shall be taken:
      i. If the -i option is in effect, the cp utility shall write a
prompt to the standard error and read a line from the standard input. If
the response is not affirmative, cp shall do nothing more with source_file
and go on to any remaining files.
      ii. A file descriptor for dest_file shall be obtained by performing
actions equivalent to the open() function defined in the System Interfaces
volume of IEEE Std 1003.1-2001 called using dest_file as the path
argument, and the bitwise-inclusive OR of O_WRONLY and O_TRUNC as the
oflag argument.
      iii. If the attempt to obtain a file descriptor fails and the -f
option is in effect, cp shall attempt to remove the file by performing
actions equivalent to the unlink() function defined in the System
Interfaces volume of IEEE Std 1003.1-2001 called using dest_file as the
path argument. If this attempt succeeds, cp shall continue with step 3b."

It doesn't matter whether you specified -if or -fi; step 3a states that if
- -i is in effect (regardless of -f), that you execute 3a.i. and prompt the
user prior to executing 3a.iii. of possibly unlinking the destination from -f.

> 
> Were you talking about the synopsys (-fip)? It doesn't look to imply
> any precedence afaic, does it?
> 
>>> Note that if accepted, the testsuite would have to be sightly altered.
>> Perhaps you could introduce a dependence on POSIXLY_CORRECT,
>> although the trend has been to avoid things like this because they
>> are harder to maintain, and have -f override -i only when not
>> POSIXLY_CORRECT.
> 
> I don't think this is needed (see above)
> 
>> But you would also do better to provide a complete patch, including
>> test suite changes, NEWS entry, and texinfo updates, before your
>> patch would be accepted.
> 
> ok
> 
>> And at that point, the patch would probably be non-trivial enough to
>> warrant an exchange of copyright papers.
> 
> that doesn't exactly lower the entry barrier :-(
> 
>> One other thing: make your patch against CVS head, not 5.93 (5.97 is
>> the latest stable release, and 6.1 has already been released as a
>> beta).
> 
> actually, it applies fine on top of 5.93.

That's my point - 5.93 is stale, and a patch should apply on top of CVS
head (6.1+).

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE9t4884KuGfSFAYARApfAAKDF+lVbI4qs4mEKoI19A3l5a2f8vQCfRjUi
jUojzLsv0W2oncdK1JYMezA=
=N7re
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]