Re: chmod don't affect referenced file of symbolic links

[Pádraig Brady]

On 16/09/2023 14:59, Pádraig Brady wrote:
> On 16/09/2023 07:26, mn wrote:
> > Hello,
> >
> > I would like to suggest and offer the code to extend chmod in a small way. My 
> > extension don’t affect referenced file of symbolic links, just avoid them 
> > silent.
> >
> > I need this ability, because I have a problem like this: Some times we need to 
> > change mode of files in a directory recursively with root privilege. For 
> > example, the directory “/opt/xxxx”, I have installed many files in the 
> > directory, and files have different owner and mode. Some mode and owner of 
> > files are wrong, so I need to fix them by a program with root privilege. For 
> > security reason, we don’t want to affect files not in that directory, like 
> > “/etc/passwd”. Then, I found ‘-h’ parameter in “chown”, it help me to protect 
> > “/etc/passwd”, but in “chmod”, there is not similar parameter not to 
> > dereference symbolic links.
> >
> > The patch is to provide “-h” in chmod, it works similar to it in “chown”. If 
> > the object file is a symbolic link, chmod skip it, and move to next file with 
> > “-h”. parameter.
> >
> > Because my system is ubuntu 22.04, it can not install vc-dwim. I have to make 
> > the patch by git directly.
>
> Currently chmod(1) will not traverse or operate on symlinks it encounters
> when recursively traversing a hierarchy.
> I.e. `chmod -R ... /opt/xxxx` would be fine for you
> (assuming xxxx was not a symlink itself).
>
> So we only need to consider the less usual case or passing
> symlinks as command line parameters here.
> However command line parameters can be filtered for symlinks
> before being passed to chmod(1), so we're not really adding
> more functionality to a shell environment at least.
> For example one could:
>
>     find /opt/xxxx \! -type l -print0 | xargs -r0 chmod ...
>
> If we were to add this functionality to chmod(1)
> it may be better to separate dir and non-dir command line param handling
> though -H,-L,-P and -h, to be more consistent with other tools.
>
> Given the points above I'm not sure if this is warranted.
> chmod has had many suggestions previously to incorporate selection
> internally, but was deemed more appropriately handled externally:
> https://www.gnu.org/software/coreutils/rejected_requests.html#chmod

Thinking about it a little more,
even though -hHLP are not as useful for chmod(1) as for chgrp(1) and chown(1),
it would be a bit more functional, and at least more consistent to add those 
options.
I'll have a look at doing that later.

cheers,
Pádraig