Hi. It occurred to me last night (20 years after first typing rm) that it would be useful in some (limited, I admit) situations to be able to give rm a numeric count of the number of things you were passing it to be removed. If rm did not find exactly (or found more) that number of file arguments, it would print a warning message and exit without removing anything.
For example, when using rm interactively from the shell, you might want to do something like this: rm -1 *.old believing that there is a single file matching *.old in your directory. From a shell script or Makefile (etc) where it is harder to confirm the number of items matched by a regex, a numeric count might be useful too. The count could either be exact or an upper limit. The advantage is pretty clear, even if slight. The main question is whether it's worth the effort to put it in and whether rm should have an option like this in the first place, etc. Of course, people should be more careful and we shouldn't encourage them to be lazy. But, people will be lazy no matter what (I even very occasionally type rm *~ or put it in a Make rule, dreading the day when I accidentally hit RETURN without the ~ or put a space between * and ~). For times when you want to be lazy but you're not 100% sure that your regex is going to match exactly one (or two, etc) things, a simple extra arg to rm would help. Regards, Terry. _______________________________________________ Bug-fileutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-fileutils