On 6/24/07, Francky Leyn <[EMAIL PROTECTED]> wrote:
What I would like is that I would be able to exclude local wastebaskets with directory name .scratch and the files in it. I would also like to be able to exclude files with a name *~ from the copy.
cd /source-dir find . -name '.scratch' -prune -o \! -name '*~' -print0 | cpio -pmd0 /dest-dir
I know I can do this with find, but it would be much more convenient if cp would have an option to exclude files from copying.
The Unix way is generally to make a tool do its designed task well, and have a separate tool for separate tasks. If you need to open a bottle of beer, it's probably better to use a bottle opener than modify your shoes to also function as a bottle opener. This adds to the power of Unix. It would really suck for example if it were impossible to do what you want because cp didn't support the exclusion of files. Being able to use several tools in combination is often very useful because it allows you to do things that the authors of the separate tools didn't envisage.
Suppose this option would be triggered with -e or --exclude
I suspect that a single-letter option may never be added to cp again (the last one was -t, in 2004, and the one before that was -H in 2000). The risk of unexpected results is probably too high. For example, someone might use the -ß option thinking it does the same thing as the -ß option on some other version of Unix and gets a nasty surprise.
I then would be able to specify the copy as: cp -rvf -e '*~' -e .scratch What about the idea? Is someone willing to implement this?
I think you're unlikely to get a volunteer. Don't forget that every new feature imposes a future burden of testing and maintenance effort. All the code in coreutils needs to be tested in preparation for every release. Every time a "horizontal" modification needs to be made through the code or the code needs to be refactored, someone will need to look at, search or check all the code. Extra code means extra effort and extra exposure to bugs. So generally, new features need to be compelling enough to justify the extra effort (or be useful but so trivial to implement that the extra effort is negligible). James. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
