On Sat, 8 Nov 2003, Bob Proulx wrote: >>% mkdir -p fred/jim >>% chmod a-x fred/jim >>% rm -rf fred >>rm: cannot chdir from `fred' to `jim': Permission denied > >But by the action of your chmod you have specifically requested that >you do not want those files removed!
But by specifying the -f option I (thought I had) specifically requested that they _should_ be removed after all! Compare: % touch foo % chmod a-w foo % rm foo rm: remove write-protected regular empty file `foo'? [C-c] % rm -f foo [removes the file without question] The -f flag or similar 'force' option is there to overrule any permissions and _force_ the files to be removed. Or so you'd think. >Changing this behavior would break a lot of safety that has been >built into scripts over the years. The behaviour cannot be changed because it would conflict with POSIX, according to earlier messages on this list. So the question is then about the usefulness of a new flag 'really force', to override permissions and remove things for certain. Yes - you could get the same effect by first doing 'chmod -R' and then 'rm -rf', but by the same argument the -f flag to cp is redundant because it just emulates rm followed by cp. I feel it makes sense to have forcing options built into the rm and cp commands themselves; of course you don't get that behaviour unless you explicitly ask for it. FWIW - what prompted me to suggest this feature was not that I had chmodded files to deliberately stop them being removed. It was just a slightly odd tarball (not generated on a Unix system, I expect) which created a directory lacking execute permission. Then I tried to use rm to clean up, and was surprised that even with the --force option it wasn't able to do the job. -- Ed Avis <[EMAIL PROTECTED]> _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
