chmod throws missing operand on 764, OK on 664

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--?

user60177

Posted 2015-01-24T20:36:56.723

Reputation: 31

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 – 2015-01-27T07:46:44.143

Answers

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'

Posted 2015-01-24T20:36:56.723

Reputation: 6 509

Thanks for the suggestion. However after checking, ls -la shows ./ to 774, and doing sudo chmod 764 -- */ still throws the missing operand error... – user60177 – 2015-01-24T21:27:27.327