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.
> 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.
Probably either because the locate database could be out of date, or because you want to do any number of things that find can do that locate can't (-mtime, -executable, -fstype, -links, etc).
Then you can add them explicitly. And what about /proc and /dev? And /sys? And /run?
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.
Most people don't want to give a thought to whitelists or blacklists, they just want to find the files relevant to them. Most people are using grep or another command piped from find, and doing 'sudo find /' (sudo to get rid of all the errors from /proc) is the easiest way to search everything.
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.
I found it interesting to compare the four chown manuals (POSIX, GNU, FreeBSD and OpenBSD) and can see why the author may have been confused about the -h switch.
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.
Back in the day you could write a core dump through a symlink. In conjunction with other bugs this made a very exploitable privilege escalation.
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.
The people who base all their knowledge of how to use computers on what they've gleaned from Stack Overflow need to find a better cargo cult. This one's already full.
I suppose people blindly following suggestions on the Internet will eventually learn a hard lesson -- don't.
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.
But the article was about a flag that you were not setting because you might not know it existed.
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).
> As it happens, I was mistaken about some aspects of the situation with chown.
---
[0]: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/ChownSymli...