Linux – python symbolic links (also to itself) in usr/bin

linuxpythonpython3symlink

I am currently playing around with cmake a bit and in the process I discovered a few things I don't understand mostly concerning python symbolic links in usr/bin directory:

In my usr/bin directory there exist symbolic links with almost the name of the python executables they point to. It seems to be a while since they were created and I want to know if there could be a reason why this is necessary or if something went wrong at some point and I should delete these symbolic links.
What are the symbolic links pointing to x86_64-linux-gnu-python<x.x>-config* for?
This is more a python specific question: What is the difference between python3.5 and python3.5m?

My usr/bin looks like this:

lrwxrwxrwx  1 root    root           9 Okt 18  2016 python -> python2.7*
lrwxrwxrwx  1 root    root           9 Okt 18  2016 python2 -> python2.7*
-rwxr-xr-x  1 root    root     3546104 Nov 19 10:35 python2.7*
lrwxrwxrwx  1 root    root          33 Nov 19 10:35 python2.7-config -> x86_64-linux-gnu-python2.7-config*
lrwxrwxrwx  1 root    root          16 Dez 10  2015 python2-config -> python2.7-config*
lrwxrwxrwx  1 root    root           9 Okt 18  2016 python3 -> python3.5*
-rwxr-xr-x  2 root    root     4460336 Nov 17 20:23 python3.5*
lrwxrwxrwx  1 root    root          33 Nov 17 20:23 python3.5-config -> x86_64-linux-gnu-python3.5-config*
-rwxr-xr-x  2 root    root     4460336 Nov 17 20:23 python3.5m*
lrwxrwxrwx  1 root    root          34 Nov 17 20:23 python3.5m-config -> x86_64-linux-gnu-python3.5m-config*
lrwxrwxrwx  1 root    root          16 Mär 23  2016 python3-config -> python3.5-config*
lrwxrwxrwx  1 root    root          10 Okt 18  2016 python3m -> python3.5m*
lrwxrwxrwx  1 root    root          17 Mär 23  2016 python3m-config -> python3.5m-config*
lrwxrwxrwx  1 root    root          16 Dez 10  2015 python-config -> python2.7-config*

Best Answer

About the python3.5m, it is the default python.

As it is in the mailing list: https://mail.python.org/pipermail/python-list/2016-June/710983.html

The "m" suffix means that Python is configured "--with-pymalloc", i.e. using specialized mallocs, including the small-object allocator. This is the default configuration. You may also see a "dm" suffix for a build that's configured "--with-pydebug" and "--with-pymalloc".

libpython3.5.so and libpython3.5m.so may actually link to the same shared library:
$ readlink libpython3.5.so
../../x86_64-linux-gnu/libpython3.5m.so.1

$ readlink libpython3.5m.so
../../x86_64-linux-gnu/libpython3.5m.so.1

About the links, they appear normal, it is just moving names and locations around to privide a standard environment for the user; from the links it can be seen the default python is 2.7 and python 3 is linking to 3.5

Related Solutions

Python – How to get ‘realpath’ to find the symbolic link

If you need to resolve (or investigate) a symlink you can use the platform independent bash library 'realpath-lib'. By default it emulates readlink and will work on Mac or Unix. It can be found on Github or Bitbucket and it's free.

But it sounds like you want to just do python2 (rather than ./python2) from your local (working) directory. It might be possible to do this with an alias in your .bashrc or otherwise you will need to add the working directory (that contains your symlink) to your PATH environment variable. This can also be done for the current session only or within the .bashrc file for future sessions. This could be a solution for just a specific user.

Another option that would work for all users would be to create the python2 symlink to /usr/bin/python in another directory on the path, say in /usr/local/bin. Perhaps something like:

sudo ln -s /usr/bin/python /usr/local/bin/python2

Then any user or script should find the python or python2 commands. Of course this option requires admin (root) privileges to install.

Links in /usr/bin or /usr/local/bin: hard or symbolic

When links are put in /usr/bin or /usr/local/bin, this is often because the actual binary is living somewhere else. Why is it living somewhere else? Usually because it is a part of a group of files, often in its own subdirectory, which it depends on to run. Why can't all those files be dumped into /usr/bin or /usr/local/bin? Because those locations are only for binaries, the binaries live at the top level of those directories, and no subdirectories are allowed.

So, why don't we use a hard link there? Because a hard link to a file is considered to be of equal status to the original file (it shares the same inode) and the file will not be deleted while there is a hard link to it. In contrast, a symbolic link is simply a pointer to "the real thing". In practice, putting a hard link to a binary file that is living somewhere else wouldn't make much sense, because if those other files in that other location/subdirectory were removed, the file could not function by itself.

An example of this are the various TeX utilities, which live in /usr/bin. If you look at them, you will see that many of them point to files that are actually in /usr/share/texlive/texmf-dist/scripts/. You can see these, for example, by doing ls -la | grep texmf.

As muru mentions, another reason is that hard links don't work across filesystems.

Another situation in which links are used for files in /usr/bin or /usr/local/bin is Debian's alternatives system. In this case, a binary may be a symbolic link pointing to a symbolic link in /etc/alternatives, which then points to the actual binary, often again itself in /usr/bin.

Example:

ls -la /usr/bin/awk 
lrwxrwxrwx 1 root root 21 Jul 31  2013 /usr/bin/awk -> /etc/alternatives/awk
ls -la /etc/alternatives/awk
lrwxrwxrwx 1 root root 13 Aug 11  2013 /etc/alternatives/awk -> /usr/bin/gawk

It is fairly obvious in this case that a symbolic link is the correct mechanism, because it is pointing to any of a range of possible binaries.

Best Answer

Related Solutions

Python – How to get ‘realpath’ to find the symbolic link

Links in /usr/bin or /usr/local/bin: hard or symbolic

Related Question