2

I was "playing around" and messed up my install of pip (Python package manager). Anyhow, it turns out, in my system /bin/pip is (?) a hard link of /usr/bin/pip (or the other way around, since I'm told with hard links there is no notion of which file is the original).

$ realpath /bin/pip /usr/bin/pip
/usr/bin/pip
/usr/bin/pip

The results of realpath have me confused. If there is no notion of which file is the original, why does realpath display /usr/bin/pip instead of /bin/pip for /bin/pip?

I know either may be a hard link because:

$ stat -c "%n is a %F pointing to inode %i, which has %h hard link(s)" /bin/pip /usr/bin/pip
/bin/pip is a regular file pointing to inode 152837, which has 1 hard link(s)
/usr/bin/pip is a regular file pointing to inode 152837, which has 1 hard link(s)

Just in case, my machine is running CentOS 7 and my realpath command comes from GNU coreutils 8.22.

-------- EDIT -------

Indeed, /bin is a symlink pointing to /usr/bin, while /usr/bin is a regular directory:

$ ls -ld /bin /usr/bin
lrwxrwxrwx. 1 root root     7 May 15 12:49 /bin -> usr/bin
dr-xr-xr-x. 2 root root 53248 Jul 13 18:44 /usr/bin
Improve this question
5
  • 4
    That is because /bin is symlink to /usr/bin
    – user996142
    Commented Jul 19, 2017 at 19:25
  • 3
    Every ordinary file has (or is) one hard link. If /bin/pip and /usr/bin/pip were hardlinks to the same diskfile, it would show as 2 hard link(s) for each in your output.
    – user4556274
    Commented Jul 19, 2017 at 19:26
  • No, every ordinary directory entry is one hard link. Files are not links, they are files.
    – Bob Eager
    Commented Jul 19, 2017 at 20:46
  • I've updated the question. Indeed, /bin is a symlink, so what does that make of the files under /bin?
    – Samuel
    Commented Jul 19, 2017 at 21:18
  • If /bin is a symlink, then the files under /bin are actually in /usr/bin! If you do ls -l /bin /usr/bin you should get two identical sets of output. The files all exist in the same directory - /usr/bin.
    – Bob Eager
    Commented Jul 19, 2017 at 22:51

1 Answer 1

Reset to default
2

I've tested this, and it doesn't happen for me. I would suspect (as suggested) that it's due to a symbolic link somewhere, since realpath resolves those.

Try: 

ls -li /bin/pip /usr/bin/pip

That should double check that the two directory entries reference the same inode/file (either directly or indirectly).

Now try: 

ls -ld /bin /usr/bin

That should show two directories (d in the first column). If one of them (almost certainly /usr/bin shows an l in that column, then it's a symbolic link, and that would explain the behaviour you are seeing (as noted earlier, realpath resolves symbolic links).

Final clarification: if one of /bin or /usr/bin is a symbolic link to the other, the realpath will follow the symlink to its target, and it'll use that target as the real path.

GNU realpath (but not all others) has the --no-symlinks option; if you use that, you'll probably get the result you originally expected.

Improve this answer
2
  • I just tested on Ubuntu, /bin isn't a symlink there!
    – Samuel
    Commented Jul 19, 2017 at 21:31
  • I don't think there are many systems where it is a symlink!
    – Bob Eager
    Commented Jul 19, 2017 at 22:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .