From coreutils manual

-L --logical Symbolic links are resolved in the specified file names, but they are resolved after any subsequent .. components are processed.

-P --physical Symbolic links are resolved in the specified file names, and they are resolved before any subsequent .. components are processed. This is the default mode of operation.

Am I correct that the difference between the two options is in the order of processing symbolic links and processing ..?

Could you explain how the two options make difference, and maybe provide some examples?


  • You are correct in that the order is changed, looking at the code the difference in -L compared to -P is that it is that the function doing the canonization (canonicalize_filename_mode) is called twice, first with the CAN_NOLINKS flag then without (latter call is like the one for -P), whereas the flag is described as Don't expand symlinks.. I still have no idea what the real-world differences are. – phk Jul 4 '16 at 23:24

Yes, the difference is in the order of processing .. and symbolic links.

Here's an example of how this can make a difference. I have an external disk mounted at /root/Archives, and a symbolic link pointing to it from my home:

$ pwd

$ ls -ld Archives
lrwxrwxrwx 1 root root 14 Oct 23  2013 Archives -> /root/Archives

realpath resolves the symlink:

$ realpath Archives

$ realpath -L Archives


$ realpath Archives/../foo

$ realpath -L Archives/../foo

With no option (or with -P) the symlink is resolved first, so Archives becomes /root/Archives, then .. is applied.

With -L the .. is applied first, so Archives/.. becomes /home/katsura, then the remaining symlinks are resolved. Since there are no symlinks left, the result is just /home/katsura.

  • thanks. is the case where a symlink is followed by .. the only case where -P and -L make difference? – Tim Jul 5 '16 at 10:40
  • @Tim Of course not. Think out of the box, there might be other symlinks along the way. Also, I've been cheating above: if /root/foo is actually a symlink to /home/katsura/foo, then the result of realpath Archives/../foo is the same as realpath -L Archives/../foo. As I said, think out of the box. – Satō Katsura Jul 5 '16 at 10:51
  • So realpath -L will return the path as it is understood by shells? Like switching to a symbollically linked directory and then typing cd .. will bring you up out of the symbolic link. – Melab Sep 10 '16 at 21:03
  • @Melab "Shells" don't do that. It's just bash and (I think) zsh that try to pretend they're doing it, by keeping track of your cds. I don't think either bash or zsh have anything to do with realpath, but yes, I suppose you can look at it that way. – Satō Katsura Sep 10 '16 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.