Re: chmod -R bug

[Bob Proulx]

Constantin Berhard wrote:
> I have a directory tree full of executable files but they should not
> be executable. So I first wanted to do a
> chmod -R -x *
> and then a
> chmod -R +X *
> so that the directories can be opened again. But chmod makes a big
> mistake with the first order: It first makes a directory unopenable
> and _then_ tries to open it recursively. There should be an
> if-statement with the -R switch so that if the mode will add opening
> permissions for directories, then it should first apply the rules to
> the directory and then open it recursively but else, if it will
> remove the opening permission for directories, then it should first
> go in recursion and then make the directory unopenable.

Thank you for the bug report.  But I am not sure this really isn't
expected behavior.  After all chmod is doing exactly what you are
telling it to do.  It just so happens that the "program" you wrote on
the command line with '-R -x *' has a bug in it.  You have told it to
remove the execute bit from *everything* and not just files.

  `-R'
  `--recursive'
     Recursively change permissions of directories and their contents.

I don't think chmod should have in it the type of control logic that
you are proposing.  It would make it more complicated and more likely
to have other bugs because of this.

In any case, you can easily accomplish the task that you want to
accomplish using 'find'.  The find command is designed to select files
based upon attributes such as whether it is a file or not.

  find . -type f -exec chmod a-x {} +

That says to:
  - find files hierarchically below the current directory dot
  - select files only, not directories or other
  - execute chmod with as many files as possible for efficiency
  - remove the execute bit from all (user, group, other)

Bob