8

I have this following code:

find ./ -iname '*phpmyadmin' -exec rm -rf {} \;

It deletes a dir called phpmyadmin, but it does not delete a file called phpMyAdmin-Version-XYZ.zip

Even if I remove the -rf, it still won't delete it (probably because a second problem with the -iname not affecting case insensitivity).

  1. Is there a way to delete any inode in a single rm (file, dir, softlink)?
  2. Why does adding the -iname not have an effect?

Note: I didn't find a "delete any inode" argument in man rm.

31

The problem is that you are matching a file that ends in phpmyadmin (case-insensitively) by using the pattern *phpmyadmin. To get any file that contains the string phpmyadmin (case-insensitively), use -iname '*phpmyadmin*':

find ./ -iname '*phpmyadmin*' -exec rm -rf {} \;

Perhaps getting the matched files before removal would be sane:

find ./ -iname '*phpmyadmin*'

To answer your first question, there is no option in rm in userspace to deal with inodes.

  • 1
    Quite possibly should consider -depth so that find doesn't try to recurse into a directory it's just deleted. – roaima May 5 '17 at 11:16
  • 8
    Not to take anything away from the answer, which does include this, but just wanted to emphasise that the reason that the OP's command did not delete the zip file was that it didn't find it, due to the lack of the trailing '*' on the pattern. – Gwyn Evans May 5 '17 at 12:59
  • 3
    @GwynEvans That also means than OP didn't test the find before adding the -exec parameter. Very dangerous. – Tulains Córdova May 5 '17 at 17:12
  • Might suggest -exec rm -rf {} + -- no point to the performance penalty of running one rm per file. – Charles Duffy May 5 '17 at 18:00
2
find ./ -iname '*phpmyadmin*' -exec /usr/lib/klibc/bin/nuke {} +

This works even if somebody creates a -phpmyadmin directory.

  • Find (at least here) prefixes the names with ./, so that's not needed: it'd execute rm -rf ./-phpmyadmin, which should work with any sane rm. Try find ./ -iname '*whatever*' -exec echo '{}' ';' to test – derobert May 5 '17 at 17:53
  • @derobert: I've had it screw up on a handful of occasions. Once bitten, twice shy. Maybe it can only happen if the argument to find is something like '-annoyingdirectoryname'. – Joshua May 5 '17 at 18:33
  • 1
    If someone ran, say, find */ instead of find ., that would do it (if a matching directory name started with a dash). That said, I'd tend to suggest using -- to handle such cases by providing an explicit end-of-options before the {} argument. (See #10 in POSIX utility syntax guidelines). – Charles Duffy May 5 '17 at 19:39
  • 1
    As an aside -- {} + is considerably more efficient than {} \;, as it'll run only as many instances of your command (nuke in this case) as necessary to fit all items found on the command line, as opposed to one-per-each. – Charles Duffy May 5 '17 at 19:42
  • @CharlesDuffy If they ran find */ then the problem wouldn't happen in -exec, the directory with a hyphen would appear to be a find option and it would complain. – Barmar May 6 '17 at 10:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.