Search code examples
bashoptimizationgnu-parallelslackwaregnu-findutils

Optimizing GNU find command with many "-o" (Boolean ∨) statements

I have the following find command that's run on source directories in Slackware SlackBuild scripts:

find -L . \
 \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \
  -o -perm 511 \) -exec chmod 755 {} \; -o \
 \( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \
  -o -perm 440 -o -perm 400 \) -exec chmod 644 {} \;

But it can be very slow for projects with many source files.

I tried speeding it up with GNU Parallel, but it didn't seem any faster:

find -L . \
 \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \
  -o -perm 511 \) | parallel --bar chmod 755
find -L .  \
 \( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \
  -o -perm 440 -o -perm 400 \) | parallel --bar chmod 644

Is there a way to optimize this find command better?

Solution

  • The immediate improvement to this is to replace -exec ... {} \; with -exec ... {} + (as @pjh suggested in a comment, though it is not necessary to split it into two find commands). This makes find run the chmod commands on batches of files (a lot like how xargs does it) rather than one at a time. Creating processes (e.g. the chmod subprocesses) is computationally expensive, and doing that fewer times will almost certainly improve performance by a lot.

    But if I understand the situation and goal properly, you can make it much simpler (and probably even faster) by using the chmod command's built-in capability to decide when to add execute permission:

    chmod -R u=rwX,go=rX .

    The capital-X symbolic mode basically means "execute permission if it makes sense" (i.e. if the item is a directory and/or already has at least one execute permission bit set).

    This is not exactly the same as your find command in a couple of ways: it'll set the perms on files with starting perms other than those in the lists of -perm flags, and will set perms to 755 for directories even if they didn't originally have execute perms set. Also, it may behave differently with symbolic links (I'm not clear on the goal of the -L flag in the original command -- are there symlinks to files outside the directory it's operating on?).