An important safety note about chown and symlinks (also chmod and chgrp)
utcc.utoronto.ca
utcc.utoronto.ca
> As it happens, I was mistaken about some aspects of the situation with chown.
---
[0]: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/ChownSymli...
In POSIX commands (like 'find'), -P means perform this operation on the physical hierarchy. (What does that mean? Physical stuff can't be recursive. So that implies symlinks aren't dereferenced.) -L means perform it on the logical hierarchy (i.e. where links are followed), and -H (not sure what it might stand for? hard links?) behaves like -P during recursion and like -L at the top level.
Unfortunately these don't explain what happens on mount points. Turns out there's also sometimes a -x or -xdev option (on Linux at least) that means "don't go across mount points". So on a command like 'find' on Linux, you probably always want -xdev in addition to -P.
No, why? A default of -P is fine but a default of -xdev would mean you couldn't search everything like find / ...
edit: Not sure where you got "physical" hierarchy. Here is the debian explanation of -P:
-P Never follow symbolic links. This is the default behaviour. When find examines or prints information a file,
and the file is a symbolic link, the information used shall be taken from the properties of the symbolic link
itself.What's the relationship between the letter P and the behavior of the option -P?
Same for the letter L and the behavior of -L, and the letter H and the behavior of -H?
That's the point the parent is making.
You usually know which mounts you want to go into, but don't have a list of every single one you want to stay out of. Most people want a whitelist here, not a blacklist.
99% of the time sys and proc and run and all that stuff won't even show up in the filtered results, and if something does, its an easy 'grep -v ^/sys' to exclude.
The POSIX manual is the only one that explicitly states that -h applies to each file operand (as opposed to files encountered during the traversal from -R). The SYNOPSIS section also makes it clear how it differs.
FreeBSD kind of gets it right, but without the word "operand" it could easily be misinterpreted.
GNU uses the word "referenced" which could also be open to misinterpretation.
The OpenBSD manual doesn't really make it clear at all, but kind of implies it with the comment about -h and -R options being mutually exclusive.
You’d think modern tooling would know better, but no. Chef can happily write templates through a symlink, and this will, bizarrely, even be the default in future.
find dirname \! -type l -exec chmod a+r {} \;
and how many people were told to do chown -R from stackoverflow?
Corollary: Learn to RTFM.
Unless you've went out of your way to avoiding installing the documentation (man pages, etc.), all the answers you need (well, most of them) are right there on your own system.
Fortunately, developers are never put under unreasonable deadlines while being evaluated by how many JIRA tickets they close and instead are always given as much time as they need to ensure that they understand all the nuances of the entire stack all the way down to the subtle behaviors of the operating system.
The logical conclusion of your argument is to ditch command line tools altogether and use graphical tools; at least then you can exhaustively review every checkbox and dropdown etc. before you click "go". Which is ironic, because from the tone of your comment I suspect you're actually a strong adherent to command line tools.
I can say I've never heard of -h/-H and never thought much about symlinks vs. chmod and I never had a problem with it because I've never thought that a symlink can have its own permission (I didn't even know such systems exist).
So for me the default of -H is fine.