-----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: > [EMAIL PROTECTED] (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 [EMAIL PROTECTED] -----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----- _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
