Re: question for cp tools
Paul Eggert [EMAIL PROTECTED] writes: OK, I've just submitted an Aardvark for this to the POSIX folks (my reference number 20050304a). ... https://www.opengroup.org/sophocles/show_mail.tpl?source=Llistname=austin-review-lid=1907 Thanks for doing that! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
Hi Bob, I've noticed that my use of `source' below might be misunderstood. Here's a snippet from the documentation that should help: mv [OPTION]... SOURCE DEST mv [OPTION]... SOURCE... DIRECTORY [EMAIL PROTECTED] (Bob Proulx) wrote: ... I know this is one of the features that you really like. Hmm... I wouldn't go that far :) I think it's a worthwhile feature, since it can help naive or careless users avoid accidentally destroying their SOURCE files. I often have cases where I have duplicate files here and there in a directory tree. For various reasons I want to move them to the archive. If they are named the same they have the same contents so I only want to keep exactly one copy of them. So I want mv */*/foo ../ARCHIVE/ mv $(find . -name foo -print)../ARCHIVE/ to move those files to the target directory. But of course with the duplicate check in place that fails. So then I started using a for loop so that it would be different mv commands. for f in */*/foo; do mv $f ../ARCHIVE/ In general, you can add mv's --backup option: mv --backup=numbered */*/foo ../ARCHIVE/ then you'll find like-named files with suffixes like .~1~, .~2~, etc. in your ARCHIVE directory. Personally, I've been happy to have mv aliased to `mv --backup=numbered' for as long as GNU mv has had that option. Of course, if they're really all the same, you won't want to archive the ~-backup files. That works but is a lot of typing. If the -f option forced the move then I would be happy with that. The documentation explicitly says it will overwrite files. -f, --force do not prompt before overwriting (equivalent to --reply=yes) Well, we can't really use -f/--force, because -f has POSIX-specified behavior controlling whether mv prompts -- not whether it refuses to do something that might be confusing. Besides, --force applies to *destination* files, which is a little ambiguous in this case, since a SOURCE file is moved to its destination, and later mv sees that renamed SOURCE file as the destination for another move. * 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 (Don't read too much sarcasm into this next statement.) I am hoping there are no plans to make this fail. touch foo bar mv foo bar Because currently that also silently clobbers files. But that is just the way I like it! :-) The key phrase above is `clobbering one of the *SOURCE* files'. The difference is that `mv foo bar' unlinks a *destination* file, which is what everyone expects mv to do. Few realize that a POSIX-compliant mv can sometimes clobber *SOURCE* files, too. Jim ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
Hi Jim Jim Meyering wrote: I've noticed that my use of `source' below might be misunderstood. Here's a snippet from the documentation that should help: mv [OPTION]... SOURCE DEST mv [OPTION]... SOURCE... DIRECTORY I can see that you are emphasizing the difference between the set of source and the set of destination files and the rules applied to those two difference sets. However, fundamentally why are they different? I don't think they should be treated differently. Note that I have never heard discussion of this with 'cp' but only with 'mv'. Fundamentally I think 'mv' and 'cp' are conceptually different. In general, you can add mv's --backup option: mv --backup=numbered */*/foo ../ARCHIVE/ So, why does --backup=numbered work but --backup=simple fail? cd /tmp rm -rf x y z mkdir x y z touch x/foo cp x/foo y/foo mv --backup=numbered x/foo y/foo z/ ls z foo foo.~1~ rm -rf x y z mkdir x y z touch x/foo cp x/foo y/foo mv --backup=simple x/foo y/foo z/ mv: will not overwrite just-created `z/foo' with `y/foo' I tried the 'mv -b' option previously and seeing that it failed stopped looking at that option thereafter and never noticed that numbered backups worked. Shouldn't they basically be the same? (I know the response is that with backup=simple you end up deleting the third SOURCE file and that violated the principle.) Well, we can't really use -f/--force, because -f has POSIX-specified behavior controlling whether mv prompts -- not whether it refuses to do something that might be confusing. Besides, --force applies to *destination* files, which is a little ambiguous in this case, since a SOURCE file is moved to its destination, and later mv sees that renamed SOURCE file as the destination for another move. I think that logic is defendable. I will acquiesce here. The difference is that `mv foo bar' unlinks a *destination* file, which is what everyone expects mv to do. Few realize that a POSIX-compliant mv can sometimes clobber *SOURCE* files, too. I understand what is happening and so that is why to me this is only annoying on the scale and not really broken. I can code around it. But I think I am sticking to using mv in a for-loop to avoid it. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
[EMAIL PROTECTED] (Bob Proulx) wrote: Jim Meyering wrote: I've noticed that my use of `source' below might be misunderstood. Here's a snippet from the documentation that should help: mv [OPTION]... SOURCE DEST mv [OPTION]... SOURCE... DIRECTORY I can see that you are emphasizing the difference between the set of source and the set of destination files and the rules applied to those two difference sets. However, fundamentally why are they different? I don't think they should be treated differently. People just `know' that preexisting destination files may be modified or removed. The manual says that, too :) The manual doesn't warn about the possibility of `mv' removing SOURCE files in some unusual cases, and doing so would seem too much like breaking an implicit contract. Note that I have never heard discussion of this with 'cp' but only with 'mv'. Fundamentally I think 'mv' and 'cp' are conceptually different. True, but sometimes people perform a move-like operation via commands like cp SOURCE... dest ... rm -rf SOURCE..., so the same logic applies. In general, you can add mv's --backup option: mv --backup=numbered */*/foo ../ARCHIVE/ So, why does --backup=numbered work but --backup=simple fail? Because detecting when --backup=simple would be safe looked like it'd be too much trouble to be worthwhile, and besides, adding code to do that would impact the usual case by increasing the size of the F_triple struct. Or we could add more code and a separate, much smaller, table just to remember names of files that are overwritten two or more times -- but that would be overkill, even if you ignored the complications of the fourth backup type (`existing' can lead to simple or numbered backups) and the fact that the new table would have to be initialized in every caller of copy (mv, cp, install). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
Jim Meyering [EMAIL PROTECTED] writes:
$ mkdir a b c
$ touch {a,b}/important.h
$ cp a/*.h b/*.h c
cp: will not overwrite just-created `c/important.h' with `b/important.h'
Hmm, does POSIX allow this behavior? I just visited
http://www.opengroup.org/onlinepubs/95399/utilities/cp.html and
it gives a pretty-specific algorithm that requires cp A B D/. to be
equivalent to cp A D/.; cp B D/..
Similarly for mv.
I assume that behavior is in there because somebody got burned one
day, and it seems like a nice feature to have. But if it doesn't
conform to POSIX, we need to either fix POSIX or change the code
somehow.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
Paul Eggert [EMAIL PROTECTED] wrote:
Jim Meyering [EMAIL PROTECTED] writes:
$ mkdir a b c
$ touch {a,b}/important.h
$ cp a/*.h b/*.h c
cp: will not overwrite just-created `c/important.h' with `b/important.h'
Hmm, does POSIX allow this behavior? I just visited
http://www.opengroup.org/onlinepubs/95399/utilities/cp.html and
it gives a pretty-specific algorithm that requires cp A B D/. to be
equivalent to cp A D/.; cp B D/..
Similarly for mv.
I assume that behavior is in there because somebody got burned one
day, and it seems like a nice feature to have. But if it doesn't
conform to POSIX, we need to either fix POSIX or change the code
somehow.
Right. My motivation for adding this `feature' was to prevent
`mv a/* b/* dir' from destroying (silently!) user data. By the
same token, a successful invocation of `cp a/* b/* dir' might well
be followed by rm -rf a b.
It's be nice to fix POSIX.
Here's the NEWS item from fileutils-4.1.1 (November 3, 2001):
* 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
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
Jim Meyering [EMAIL PROTECTED] writes: It's be nice to fix POSIX. OK, I've just submitted an Aardvark for this to the POSIX folks (my reference number 20050304a). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
Jim Meyering wrote: Right. My motivation for adding this `feature' was to prevent `mv a/* b/* dir' from destroying (silently!) user data. By the same token, a successful invocation of `cp a/* b/* dir' might well be followed by rm -rf a b. I know this is one of the features that you really like. So I have not said anything previously. But I would have to file this as being one of the most annoying features to have been added in recent years. I often have cases where I have duplicate files here and there in a directory tree. For various reasons I want to move them to the archive. If they are named the same they have the same contents so I only want to keep exactly one copy of them. So I want mv */*/foo ../ARCHIVE/ mv $(find . -name foo -print)../ARCHIVE/ to move those files to the target directory. But of course with the duplicate check in place that fails. So then I started using a for loop so that it would be different mv commands. for f in */*/foo; do mv $f ../ARCHIVE/ That works but is a lot of typing. If the -f option forced the move then I would be happy with that. The documentation explicitly says it will overwrite files. -f, --force do not prompt before overwriting (equivalent to --reply=yes) mv -f */*/foo ../ARCHIVE/ # does not force But of course that does not turn this behavior off. So actually I use the for loop most of the time. Finger memory and all of that. It's be nice to fix POSIX. I would rather see the previous behavior restored. Here's the NEWS item from fileutils-4.1.1 (November 3, 2001): * 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 (Don't read too much sarcasm into this next statement.) I am hoping there are no plans to make this fail. touch foo bar mv foo bar Because currently that also silently clobbers files. But that is just the way I like it! Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: question for cp tools
¤´Æ [EMAIL PROTECTED] wrote:
Hello. I have a question for cp tools.
CP tool is so convenient for make processing, but I¡¯ve had trouble with
copying some files.
cp: will not overwrite just-created `../../1H/uimdrv.h' with
`../../services/uim/uimdrv.h'
cp: will not overwrite just-created `../../1H/sisdecoder.h' with
`../../midp/sisdecoder.h'
That is a feature of cp that is designed to prevent
accidental data loss in a case like yours:
$ mkdir a b c
$ touch {a,b}/important.h
$ cp a/*.h b/*.h c
cp: will not overwrite just-created `c/important.h' with `b/important.h'
So, you have at least two pairs of header files with the same name
but in different directories.
If you really want to use only one copy of such a file (maybe they're
identical), you can use cp's --backup option, and you'll find important.h
and important.h~ in the destination directory. However, it's almost
always better to avoid having identically-named files.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
