Someone messed up symbolic links on redhat server and I can't use python now, I tried a lot of things. When I try to run python I get python: command not found.
I have this information:
alternatives --display python
python - status is auto.
link currently points to /usr/bin/python2.4
/usr/bin/python2.4 - priority 1
Current `best' version is /usr/bin/python2.4.
When I try to change ln -sf /usr/bin/python /usr/bin/python2.4 I get the following:
ln: accessing `/usr/bin/python2.4': Too many levels of symbolic links
When I remove /usr/bin/python it doesn't help as well.
I also cheched it with these commands:
readlink /usr/bin/python
/etc/alternatives/python
readlink /usr/bin/python2.4
/usr/bin/python
readlink python
/usr/bin/python
It looks like everything should work fine. Any suggestions?
I think you have the ln command backwards. The reason you are getting this error is because you are creating a link python2.4 that points to python, but python is a link pointing to python2.4. Reverse your source and destination in the ln command and it should work.
I've never used alternatives, but you probably shouldn't be manually editing these symlinks.
Edit:
As I mentioned in my comment, you may have overwritten the original python binary. On a RHEL5 system I have access to here's what the /usr/bin directory looks like:
$ ls -l /usr/bin/python*
-rwxr-xr-x 2 root root 8304 Oct 23 2012 /usr/bin/python
lrwxrwxrwx 1 root root 6 Jan 11 2013 /usr/bin/python2 -> python
-rwxr-xr-x 2 root root 8304 Oct 23 2012 /usr/bin/python2.4
And if you look at the inodes of the two non-symlink files you'll see that they are the same file:
$ stat -c %i /usr/bin/python
3290164
$ stat -c %i /usr/bin/python2.4
3290164
So you need to find the original python binary then we can figure out how to link them the original way. And again, I've never used alternatives so maybe it does some magic of moving the binaries around, but I doubt it.
Related
Here is the docker run output:
hausey#ubuntu:~/niso2-jxj934$ docker run niso2-jxj934
Test version: 15:59, Mar 24th 2020
Question 1: Evaluation of expression.
Command failed: /bin/bash -c "python /bin/jxj934.py -question 1 -expr \"(ifleq (ifleq -1.11298616747 1.63619642199 (sub -1.11298616747 -1.11298616747) 1.7699684348) (add (exp -0.822479932786) 1.39992604386) (add -1.11298616747 (exp 0.385042309638)) 0.205973267133)\" -n 10 -x \"-0.168958230447 -0.131749160548 0.0971246476126 1.8706205565 -0.464122426299 2.35887369763 -0.375948313434 -0.613901105864 0.411326743135 -0.149276696072\"" Exit status: exited with code 127 stderr: /bin/bash: python: command not found
Here is the Dockerfile:
FROM pklehre/niso2020-lab2-msc
ADD jxj934.py /bin
CMD ["-username","jxj934", "-submission", "python /bin/jxj934.py"]
Here is check for python:
hausey#ubuntu:~/niso2-jxj934$ which python
/usr/bin/python
Is that related to the PATH of python?
Usually, it is related to the value of PATH but, specifically, that image only has python3. In other words, looking through the filesystem with
find / -name -type f "python*"
Look for regular files named "python*" in /
There were only python3 results.
...
/usr/bin/python3.8
/usr/bin/python3.7
...
A quick solution is to specify python3 in your CMD line (python3 /bin/jxj934.py). Another is to add a soft link (ln -s /usr/bin/python /usr/bin/python3.8). The best solution is to solve it using the package manager. Then again, that depends if you're in control of the Dockerfile + image.
When you queried which python, you did so on your local machine. The container runs in a different filesystem namespace than yours and with a completely different terminal. The container will behave differently than your machine and any such investigations will yield relevant results only when run within the container.
A little unrelated to your question but it might serve you.
docker run has a --entrypoint option that allows you to override the image's entrypoint. You can ask for bash and explore the container.
docker run --it --entrypoint=bash pklehre/niso2020-lab2-msc
Note that bash has to be in the $PATH.
By default when I type python in terminal it goes to python using the 2.7.x version. In oldest versions of macOS once I typed 'alias pyhton=python3' it changed forever and every time I typed python it goes to python version 3.
But in macOS Catalina, I need to type the statement every time I open the terminal.
Any suggestion?
First up, confirm what your default "python" links to, so you can reference it, and ensure that which and the shell agree:
user:~> which python
/usr/bin/python
user:~> type python
python is /usr/bin/python
user:~> ls -la /usr/bin/python
lrwxrwxrwx 1 root root 7 Oct 8 13:26 /usr/bin/python -> python2
Now you can either add an alias to override this in your shell... .
Open your ~/.bash_profile file for bash or ~/.zshrc file for zsh (look here for historical reasons behind the files used) as suggested by shahaf, and add a line with the alias — for example, quick method:
echo "alias python=/usr/bin/python3" >> ~/.bash_profile
echo "alias python=/usr/bin/python3" >> ~/.zshrc
The new alias will be set for the next shell you start, or, open a new Terminal window and source the profile file to make it active. Eg. in bash:
source ~/.bash_profile
Or, change the symlink to point by default to python3, and remember the change (I use a simple toggle script, else any install of a missing python2 package can result in complaints about the configure script, which uses the python symlink directly):
#!/bin/bash
TOGGLE=$HOME/.python3Active
if [ ! -e $TOGGLE ]; then
touch $TOGGLE
sudo ln -fs python3 /usr/bin/python
ls -la /usr/bin/python
echo "Press any key to continue..."
read
else
rm $TOGGLE
sudo ln -fs python2 /usr/bin/python
ls -la /usr/bin/python
echo "Press any key to continue..."
read
fi
Catalina now uses zsh as the default rather than Bash.
To verify which shell you are using type echo $0 in the terminal
Add alias python='python3' to $HOME/.zshrc
you will have to edit the terminal's profile file, usually reside under ~/.profile
add the alias line there, this files get loaded when a terminal session is started and export environment variables and methods so they will be accessible in that session
I suggest to use a more robust and powerful terminal enhancement like Z-Shell
To get flycheck working for Python, I had reached a satisfactory .emacs, which turned out to require no more than:
(require 'flycheck)
(add-hook 'after-init-hook #'global-flycheck-mode)
Now after a bit of looking forward at what Python 3.6 will be like, even a two-liner
class Foo():
pass
gets a whole slew of warnings:
Too few public methods (0/2) [too-few-public-methods]
Class has no __init__ method [no-init]
Old-style class defined. [old-style-class]
Missing class docstring [missing-docstring]
Missing module docstring [missing-docstring]
despite that I'm now firmly back in 2.7 (sudo port select --set python python27).
Emacs gets us used to being context-agnostic. It usually doesn't matter what is on the system; one gets the same behavior if one starts from an unchanged .emacs. What else might have changed in my system to trigger a sudden increase in flycheck warnings?
OK, I found the answer.
flycheck chooses (silently?) flake8, and if that is not found, it falls back on pylint (and subsequently on pycompile).
The problem was that the symlink flake8 had vanished. Here is why/how.
After selecting python36 and back
~/ > sudo port select --set python python36
~/ > sudo port select --set python python27
and after selecting pip36 and back
~/ > sudo port select --set pip pip36
~/ > sudo port select --set pip pip27
the symlink /opt/local/bin/flake8 disappears. Only flake8-2.7 is left.
> ls -l /opt/local/bin/flake8*
lrwxr-xr-x 1 root admin 70 20 Mar 16:35 /opt/local/bin/flake8-2.7 -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/flake8
What happens, presumably, is that flake8 points to nothing (port select is updated, and the symlink is removed) when you update to Python 3.6 but do not have flake8-36. The symlink cannot be reinstated when you downgrade to Python 2.7 (one of these, perhaps the former, merits a warning—maybe as a minor bug in MacPorts).
~/ > sudo port select --list flake8
Available versions for flake8:
flake8-27
none (active)
The solution is to explicitly point flake8 to flake8-27 when you downgrade.
~/ > sudo port select --set flake8 flake8-27
Selecting 'flake8-27' for 'flake8' succeeded. 'flake8-27' is now active.
And the link comes back and flycheck chooses flake8 over pylint.
> ls -l /opt/local/bin/flake8*
lrwxr-xr-x 1 root admin 25 7 Sep 09:01 /opt/local/bin/flake8 -> /opt/local/bin/flake8-2.7
lrwxr-xr-x 1 root admin 70 20 Mar 16:35 /opt/local/bin/flake8-2.7 -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/flake8
Might be better to setup minor mode hook or only add to programming mode
(add-hook 'prog-mode-hook 'flycheck-mode)
By setting it to global will enable it in every buffer even in text mode like org mode which is not needed. Also might slow things down. :)
I'm trying to create a python source package, but it fails when creating hard links for files.
$ python setup.py sdist
running sdist
running check
reading manifest template 'MANIFEST.in'
writing manifest file 'MANIFEST'
making hard links in foo-0.1...
hard linking README.txt -> foo-0.1
error: Operation not permitted
I've tried running the command with sudo, but it produces the same error.
This also produces the same error:
ln foo bar
I'm using vbox to run a virtual instance of ubuntu, which is probably where the problem comes from. Is there a way round using hard links when creating source distributions?
System information:
Ubuntu server 11.04;
VirtualBox 4.14;
osx 10.6.6;
python 2.7.1;
Same issue. I am using vagrant, my host OS is Windows while the Gust OS is Ubuntu. I am not a vim fan, so #simo's answer does not help me much because I really rely on virtual box shared folders to sync changes made by sublime editor to the Ubuntu virtual machine.
Thanks to Fabian Kochem, he found a quick and dirty workaround: post
# if you are not using vagrant, just delete os.link directly,
# The hard link only saves a little disk space, so you should not care
if os.environ.get('USER','') == 'vagrant':
del os.link
I ran into the same issues.
I was able to get it working by moving the python sources from the virtual box shared folder to my debian home folder. No error on sdist anymore.
I hope it helps.
It is unclear from your question what step is failing. Might be the hard linking right before the error. You can try strace to see what system call is failing. That should give a better picture of the problem at least.
This python bug report looks like they're not going to fix this until distutils2. Someone did supply a patch that might be useful to you. You might also be able to mount a directory over NFS and build there. I believe that NFS allows hard linking.
Looks like this was fixed in Python version 2.7.9 - https://hg.python.org/cpython/raw-file/v2.7.9/Misc/NEWS
Issue #8876: distutils now falls back to copying files when hard linking
doesn't work. This allows use with special filesystems such as VirtualBox
shared folders
This is the way I reached a working uwsgi(Ubuntu 14.04, default Python 2.7.6) with Python-2.7.10.
Steps
Before continuing, you must compile new Python with --enable-shared:
$ ./configure --enabled-shared
$ sudo make altinstall
Context: Ubuntu 14.04 with Python 2.7.6 with uwsgi and uwsgi-python-plugin installed with apt-get
Problem: I have a virtualenv for my all with compiled Python-2.7.10
# Previously installed Python-2.7.10 as altinstall
$ python2.7
Python 2.7.10 (default, Nov 25 2015, 11:21:38)
$ source ~/env/bin/activate
$ python
Python 2.7.10 (default, Nov 25 2015, 11:21:38)
Preparing stuff:
$ cd /tmp/
$ git clone https://github.com/unbit/uwsgi.git
$ cd uwsgi
$ make PROFILE=nolang
# On /tmp/uwsgi
$ PYTHON=python ./uwsgi --build-plugin "plugins/python python27"
On ini file:
[uwsgi]
plugins = python27
Results on:
** Starting uWSGI 1.9.17.1-debian (64bit) on [Thu Nov 26 12:56:42 2015] ***
compiled with version: 4.8.2 on 23 March 2014 17:15:32
os: Linux-3.19.0-33-generic #38~14.04.1-Ubuntu SMP Fri Nov 6 18:17:28 UTC 2015
nodename: maquinote
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 12
current working directory: /etc/uwsgi/apps-enabled
detected binary path: /usr/bin/uwsgi-core
your processes number limit is 257565
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: enabled
uwsgi socket 0 bound to UNIX address /var/run/uwsgi/app/pypi-server/socket fd 3
Python version: 2.7.10 (default, Nov 26 2015, 11:44:40) [GCC 4.8.4]
None of the above answers solved my problem. However, I was running the following command in a vagrant shared folder on Centos 6:
python setup.py bdist_bdrpm
And ended up with the error:
ln: creating hard link `xxx': Operation not permitted
error: Bad exit status from /var/tmp/rpm-tmp.S9pTDl (%install)
It turns out that it's a bash file that eventually executes the hard links:
cat /usr/lib/rpm/redhat/brp-python-hardlink
#!/bin/sh
# If using normal root, avoid changing anything.
if [ -z "$RPM_BUILD_ROOT" -o "$RPM_BUILD_ROOT" = "/" ]; then
exit 0
fi
# Hardlink identical *.pyc and *.pyo, originally from PLD's rpm-build-macros
# Modified to use sha1sum instead of cmp to avoid a diffutils dependency.
find "$RPM_BUILD_ROOT" -type f -name "*.pyc" | while read pyc ; do
pyo="$(echo $pyc | sed -e 's/.pyc$/.pyo/')"
if [ -f "$pyo" ] ; then
csha="$(sha1sum -b $pyc | cut -d' ' -f 1)" && \
osha="$(sha1sum -b $pyo | cut -d' ' -f 1)" && \
if [ "$csha" = "$osha" ] ; then
ln -f "$pyc" "$pyo"
fi
fi
done
Therefore you should be able to replace the hard link ln -f "$pyc" "$pyo" with a copy command cp "$pyc" "$pyo" in the above shell script.
I'm a bit confused with what is happening to run my django apps. When I use the command python manage.py runserver I don't get the appropriate response from the server. However, when I use python2.6 manage.py runserver the server actually runs.
Can someone help me with this confusion and also suggest to me how I can simplify this problem? Ideally I don't want different versions of python and only want to be able to type python manage.py runserver
Yes. It is fairly common. You can find out the location of an executable with which, and resolve symlinks with ls.
$ ls -l `which python`
lrwxrwxrwx 1 root root 9 Jul 13 18:50 /usr/bin/python -> python2.6
$ ls -l `which python3`
lrwxrwxrwx 1 root root 9 Jul 27 22:24 /usr/bin/python3 -> python3.1
On Debian and some other systems, you may need to resolve multiple symlinks.
$ ls -l `which nc`
lrwxrwxrwx 1 root root 20 Oct 7 15:16 /bin/nc -> /etc/alternatives/nc
$ ls -l /etc/alternatives/nc
lrwxrwxrwx 1 root root 15 Oct 7 15:16 /etc/alternatives/nc -> /bin/nc.openbsd
If you want to only type python and get the version you want, make an alias. Add a line to your .bashrc file (or wherever you keep such lines):
alias python=python2.6
Note that this will not affect scripts: if you run "python" in a script, it will get the old version, not an alias. Aliases are only for interactive use.
Yes, it is possible to have two versions of python. The easiest way I've found to make python execute python2.6 (without breaking the other version for anyone else) is by using an alias. To do this, simply edit the following and add it to your ~/.profile file:
alias python=/path/to/your/python2.6
Log out and back in, and when you run python it should execute the correct binary. If you wish to revert back, simply delete this line from your ~/.profile.
Yes, you can have multiple versions of Python sitting side-by-side on your computer.
It sounds like python on your host is symbolically linked to a version other than python2.6. You can find out this version by running:
python --version
...or...
python -V
...if that does not work.
Setting the default Python version depends on how you installed Python in the first place.
For Mac OS X, see How can I change the default Python version on Snow Leopard?