2

Having set everything in my project to 777 (rwxrwxrwx) for debugging purposes, I wanted to dial down the openness and set the directories (not the files) in the root folder to 664 (rw-rw-r--).

To do this I used (from How to list folders using bash commands?):

chmod 664 -- */

This worked as expected. Then I realized I needed the execution bit on directories to enter them. So I tried:

chmod 764 -- */

But that threw a missing operand after "764" error.

I can change the permissions by hand (chmod 764 <dir-name>) and there aren't that many directories so it's not a big problem, but I'd like to understand.

Why can't I use chmod 764 */ to set the directories in my current path to rwxrw-r--?

Community
  • 1
user60177
  • 71
  • 1
  • 3
  • Not an answer to your question, but you may like to know that `chmod +X` (possibly together with `--recursive`) would be appropriate for this situation; it grants execute/search permission only if a file is a directory or already had execute permission (from `info '(coreutils.info.gz)Conditional Executability'`). – Edward Jan 27 '15 at 07:46

1 Answers1

1

This would make sense if you have set shell glob options so that

  • * includes names beginning with ., and
  • a wildcard that doesn’t match anything just disappears, rather than persisting as itself.  (E.g., if you don’t have any files whose names begin with foo, the command echo foo* prints a blank line rather than printing foo* literally.)

If the above are true, then the first command set . to mode 664, which means that you didn’t have permission to read . when you issued the second command.  So the */ couldn’t be expanded, and chmod 764 -- */ became chmod 764 --.

G-Man Says 'Reinstate Monica'
  • 7,678
  • 22
  • 41
  • 87
  • Thanks for the suggestion. However after checking, `ls -la` shows `./` to `774`, and doing `sudo chmod 764 -- */` still throws the missing operand error... – user60177 Jan 24 '15 at 21:27