I’m working with some old software and in general everything is working well. Recently migrated from CentOS 7 to AlmaLinux 9 and have been working through things.
This software was designed for Python 2 and of course system default now is version 3.
I have all the software running on its own user separated from the root account. I modified the top of the .bashrc file like so: # .bashrc
# Source global definitions if [ -f /etc/bashrc ]; then
. /etc/bashrc* fi
export PATH=“/usr/bin/python2.7:$PATH” alias python=python2.7
When I run a Python script like so:
“python scriptname.py” or “python2 scriptname.py” it works fine.
When I run the same script like so:
“./scriptname.py” it defaults to Python 3 and has issues.
As a temporary fix I’ve modified the symbolic link of the file /usr/bin/python to point to python2 instead of python3 and now the bash / shell environment selects Python 2 by default as I want.
However, I am concerned that long-term this may cause issues considering the OS is designed to use version 3 and if I’m not mistaken this change will be system-wide, not solely for this user.
Is there a better way I can do this to make all commands for that specific user use Python 2 - even if they are not prefaced with python but leave the root and other accounts to still default to version 3?
Thanks in advance for any help!
Edit: I suppose I could just modify this symbolic link whenever I wish to run system updates etc back to version 3 to make sure I don’t break the OS then switch it back to 2 after?
First of all, I did not know that there is Python 2.7 for el9. If there are no Python 2.7 packages for el9, then you must have a “source install” and one should non sprinkle those files in the midst of files from packages.
That is good and proper. That would also include installing the Python 2.7 as regular user to path that the regular user can write to (i.e. without ‘sudo’).
Note: The default .bashrc for regular user does look like:
# .bashrc
# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi
# User specific environment
if ! [[ "$PATH" =~ "$HOME/.local/bin:$HOME/bin:" ]]
then
PATH="$HOME/.local/bin:$HOME/bin:$PATH"
fi
export PATH
# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=
# User specific aliases and functions
if [ -d ~/.bashrc.d ]; then
for rc in ~/.bashrc.d/*; do
if [ -f "$rc" ]; then
. "$rc"
fi
done
fi
unset rc
There is no need to edit it. At all. Do notice the use of directory ~/.bashrc.d
That does not exist by default, but you can make one: mkdir ~/.bashrc.d
Then you can add a file to that directory and all your customizations to that file (or files.
This makes it easier for you to see what customizations this user has.
First, your PATH tells bash to look executables from directory/usr/bin/python2.7 before it looks from other directories. Is that really a directory? The /usr/bin is expected to have executable files, not directories.
If the /usr/bin/python2.7 is an executable, then PATH would have /usr/bin, but that it already has.
The command filename (e.g. python scriptname.py ) tells bash to execute the command and pass the filename to the command and argument. The python treats files that it gets as arguments as python code that it executes. Therefore, the python runs the script.
If filename is marked executable, then ./scriptname.py means to bash:
"Run the file scriptname.py, which is in current directory, as command.
Since the “command” is text, bash does look at the first line of it. If there is
#!something
Then bash will essentially convert ./scriptname.py into something scriptname.py
What should the something be? Most likely are:
#!/usr/bin/python
an absolute path to command that can handle this (script) file, or
#!/usr/bin/env python
The command env seeks name “python” from PATH, etc and hands that to bash as the “command” to run.
If you could update your ‘scriptname.py’ to point to the correct Python (python2) in the #!, then the shorter syntax should work.
A look back at the .bashrc shows that regular user has two directories:
~/.local/bin
~/bin
that are already on the PATH. You could move your scriptname.py and/or python executable/symlink to either of those directories, and then bash should find them (without the ./).
If you have a source of program, for which install instructions are:
./configure
make
sudo make install
Then an alternative could be:
./configure --PREFIX=${HOME}/.local
make
make install
and the executable of the program should end up in ${HOME}/.local/bin (which is on the PATH).
Thank-you both very much for taking the time to help and explain
I ran into some other problems to solve so have been busy but there is indeed this line at the top of the script. I was concerned about modifying it because the script is being called by the old software.
I believe it should most likely work fine though and allow me to keep Python 3 as the system’s main version, will test it out soon.
