GNU bug report logs - #8729
RFE: chmod "-D" operate on dir's only

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8729 in the body.
You can then email your comments to 8729 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: bug-coreutils <at> gnu.org
Subject: RFE: chmod "-D" operate on dir's only
Date: Tue, 24 May 2011 18:57:02 -0700

I know one can (and I usually do) construct a find command to do
this, but it's something I do so often, and it's a natural 'pair'
for what is often done with chmod.

If I want to make sure a dir tree is readable/accessable
by a group or other, I usually do:

 chmod -R g+r,o+r .
 find . -type d -print0|xargs -0 chmod g+x,o+x

What'd be a great addition to chmod is for it to have an option
for chmod to only work on dirs.  (is -D taken?)

So instead of the 2nd line above:

 chmod -DR g+x,o+x

----
What'cha think?

Is that a useful and logical addition for chmod?

Message #10 received at 8729-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 8729-done <at> debbugs.gnu.org
Subject: Re: bug#8729: RFE: chmod "-D" operate on dir's only
Date: Wed, 25 May 2011 09:22:28 +0100

On 25/05/11 02:57, Linda Walsh wrote:
> I know one can (and I usually do) construct a find command to do
> this, but it's something I do so often, and it's a natural 'pair'
> for what is often done with chmod.
> 
> If I want to make sure a dir tree is readable/accessable
> by a group or other, I usually do:
> 
>  chmod -R g+r,o+r .
>  find . -type d -print0|xargs -0 chmod g+x,o+x
> 
> What'd be a great addition to chmod is for it to have an option
> for chmod to only work on dirs.  (is -D taken?)
> 
> So instead of the 2nd line above:
> 
>  chmod -DR g+x,o+x

This was discussed before (the link is down ATM):
http://lists.gnu.org/archive/html/bug-coreutils/2010-02/msg00201.html

IIRC `chmod -R go+rX .` was deemed sufficient.
That will have the caveat of making existing executables,
executable by everyone.

I'll close this for now.

thanks,
Pádraig.

Message #13 received at 8729 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 8729 <at> debbugs.gnu.org
Subject: Re: bug#8729: RFE: chmod "-D" operate on dir's only
Date: Wed, 25 May 2011 07:54:08 -0600

[Message part 1 (text/plain, inline)]

On 05/24/2011 07:57 PM, Linda Walsh wrote:
> I know one can (and I usually do) construct a find command to do
> this, but it's something I do so often, and it's a natural 'pair'
> for what is often done with chmod.
> 
> If I want to make sure a dir tree is readable/accessable
> by a group or other, I usually do:
> 
>  chmod -R g+r,o+r .
>  find . -type d -print0|xargs -0 chmod g+x,o+x
> 
> What'd be a great addition to chmod is for it to have an option
> for chmod to only work on dirs.  (is -D taken?)
> 
> So instead of the 2nd line above:
> 
>  chmod -DR g+x,o+x
> 
> ----
> What'cha think?

I think that you are better off using what POSIX has already
standardized for chmod:

chmod -R go+rX .

which says for all files in the hierarchy, add read bits for group and
others to files and directories, and add execute bits only for files and
directories that were already executable by the user.  Thus
non-executable files (since your directories likely already have the u+x
permission, since a non-searchable directory is rare) are not granted
execute permissions, while directories are nicely handled without
needing a followup find|xargs.

> 
> Is that a useful and logical addition for chmod?

It's not a very strong case, and certainly not strong enough to burn a
short option letter for.  But if you want to pursue the idea, a patch
with a long option name (instead of short option), documentation, and
test cases, as well as rationale why relying on already standardized
tools is inefficient, may sway my mind.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #16 received at 8729 <at> debbugs.gnu.org (full text, mbox):

From: Linda Walsh <coreutils <at> tlinx.org>
To: Eric Blake <eblake <at> redhat.com>
Cc: 8729 <at> debbugs.gnu.org
Subject: Re: bug#8729: RFE: chmod "-D" operate on dir's only
Date: Wed, 25 May 2011 10:12:51 -0700

Eric Blake wrote:
> 
> I think that you are better off using what POSIX has already
> standardized for chmod:
> 
> chmod -R go+rX .
---
> 
> which says for all files in the hierarchy, add read bits for group and
> others to files and directories, and add execute bits only for files and
> directories that were already executable by the user.  Thus
> non-executable files (since your directories likely already have the u+x
> permission, since a non-searchable directory is rare) are not granted
> execute permissions, while directories are nicely handled without
> needing a followup find|xargs.
----
	That's what a capital X does?   Huh....how interesting...  That'll
work for my purposes usually, ...damn cryptic, if you ask me, but so what... I
I do see it in the man page, but I thought cap-x was used for something else,
as I've seen it in the output of 'ls' occasionally...

Maybe it's an unrelated usage.


Thanks!
Should work for most my cases...

Message #17 received at 8729-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Linda Walsh <coreutils <at> tlinx.org>
Cc: 8729-done <at> debbugs.gnu.org
Subject: Re: bug#8729: RFE: chmod "-D" operate on dir's only
Date: Wed, 25 May 2011 11:30:59 -0600

[Message part 1 (text/plain, inline)]

tag 8729 notabug
close 8729
thanks

On 05/25/2011 11:12 AM, Linda Walsh wrote:
>     That's what a capital X does?   Huh....how interesting...  That'll
> work for my purposes usually, ...damn cryptic, if you ask me, but so
> what... I
> I do see it in the man page, but I thought cap-x was used for something
> else,

The info pages are more complete on this topic (the man page comes from
'chmod --help' output, which is necessarily terse).  See "Conditional
Executability" under 'info coreutils "Symbolic Modes"'.

You are welcome to submit patches to improve clarity [at which point we
could reopen this bug], but for now, I'm marking this bug as closed.

> as I've seen it in the output of 'ls' occasionally...
>
> Maybe it's an unrelated usage.

I'm not sure I've seen 'X' used in ls output.  I've seen 's', 'S', 't',
'T', 'l', and 'L' in place of the traditional '-', 'x'; all according to
the state of the special bit associated with that particular 'x'
position, and whether the special bit is set without the executable bit
also set.

So I guess an 'X' designation from ls might occur on some implementation
that wants to flag your attention that a special bit is set but the x
bit is not, but where that setting makes no sense unless the x bit is
also turned on (that is, an alternative to 'S', 'T', or 'L'), but
neither coreutils, Solaris, nor BSD ls will output 'X'.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.