I think that when -f is specified, the old behavior (last source file specified on the command line silently wins) should occur.
Thanks, vin Jim Meyering <[EMAIL PROTECTED]> writes: > Thanks for reporting that. > I've just added this to the NEWS file for 4.1.1: > > * mv (likewise for cp), now fails rather than silently clobbering one of > the source files in the following example: > rm -rf a b c; mkdir a b c; touch a/f b/f; mv a/f b/f c > > I'm not sure what behavior would be best in your case: > > touch a; mkdir d > cp a a d > > It might make sense to have -f cause your example to succeed (colliding > source files are the same), but not the one above that motivated that > behavior change (colliding source files are different). I'll look > into it. > > Vin Shelton <[EMAIL PROTECTED]> wrote: > > In fileutils-4.1, if a file is listed twice in the source list, cp > > copies the file twice, overwriting the first copy. In > > fileutils-4.1.1, cp generates an error, even if the -f flag has been > > specified: > > > > in fileutils-4.1.1: > > $ touch baz > > $ mkdir blurfl > > $ /usr/local/bin/cp --version > > cp (fileutils) 4.1.1 > ... > > $ /usr/local/bin/cp baz baz blurfl > > /usr/local/bin/cp: will not overwrite just-created `blurfl/baz' with `baz' > > $ /usr/local/bin/cp -f baz baz blurfl > > /usr/local/bin/cp: will not overwrite just-created `blurfl/baz' with `baz' > > > > in fileutils-4.1: > > $ /bin/cp --version > > cp (fileutils) 4.1 > ... > > $ /bin/cp baz baz blurfl > > $ echo $? > > 0 > > > > I did not find this change mentioned in the NEWS file. This change > > will likely break some scripts and makefiles which utilize the old > > 'feature'; I discovered it when building the XEmacs packages > > hierarchy, which contains makefiles which (admittedly sloppily) use > > macros to supply overlapping lists of source files for cp to copy. _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils
