Как исправить – bash: python: command not found Error

1. Проверьте Установленный Python

В большинстве случаев эта ошибка возникает в командной строке, потому что python не установлен или поврежден. Давайте сначала проверим, установлен Python или нет.

Выполните следующие команды, чтобы найти установленное местоположение python.

$ which python3

или введите команду

$ type -a python3

Терминал ответит:

python3 is /usr/bin/python3python3 is /bin/python3

или выдаст такой ответ:

$ ls -l /usr/bin/python
$ ls -l /usr/local/bin

Следующая команда проверит версии python:

$ python3 —version

Простая команда run python3:

$ python3
Python 3.8.2 (default, Jul 16 2020, 14:00:26)
[GCC 9.3.0] on linux
Type «help», «copyright», «credits» or «license» for more information.

Если python у вас не установлен, то в следующем разделе я покажу вам, как установить python .

Установите Python на Ubuntu/Debian

Установите Python на Ubuntu

Debian и Ubuntu, а так же их производные дистрибутивы поставляются с предустановленным python. В случае, если он поврежден или не установлен, используйте следующую команду.

$ sudo apt install python

Примечание: приведенная выше команда установит python версии 2.

Python 2 После 1 января 2020 года Python 2 больше не получает никаких обновлений и не рекомендует его использовать.

или

Возможно вам будет интересно:  Установка PHP 7.4 на Ubuntu 20.04

Чтобы установить python 3, Введите команду:

$ sudo apt install python3

Python установленный из исходного кода, по умолчанию устанавливается в ‘http://usr/local/bin/’. В этом случае ввод python на консоли будет выполняться не внутри файла /usr/local/bin/, а внутри файла /usr/bin/.

Если вы хотите выполнить его внутри файла /usr/local/bin/, вы можете легко настроить систему, используя псевдоним (алиас). Псевдоним должен быть помещен в файл. bashrc, как показано ниже.

alias python=/usr/local/bin/python3.9

Установите Python на Fedora

Благодаря менеджеру пакетов dnf вы можете легко установить python на Fedora с помощью:

$ sudo dnf install python38

Установите Python на RHEL/CentOS

Чтобы установить Python на RHEL, Oracle Linux и CentOS, используйте команду yum следующим образом:

$ sudo yum install python

Установите Python на Arch Linux

В Arch Linux выполните следующую команду для установки python:

$ sudo pacman -S python2
$ sudo pacman -S python3

Тут сказано поднять простой сервер на node.js. Можно ли такое поднять на Python?

• 1 подписчик
• 12 часов назад
• 83 просмотра

ответ
1

• Windows

• +1 ещё

Простой

Как убрать предупреждение об экспериментальной функции?

• 2 подписчика
• вчера
• 51 просмотр

ответов
0

• Node.js

• +1 ещё

Простой

The available solutions

There are 3 ways to solve this problem if you encounter it on your remote host:

1. Set ansible_python_interpreter: /usr/bin/python3 variable for all hosts that have python3 installed by default
2. Install Python 2 using Ansible’s raw module
3. Symlink /usr/bin/python3 to /usr/bin/python using Ansible’s raw module

All 3 options can be done in Ansible, without sshing into the host, which is good news for us (and automation). In the following sections I’ll show how you can use each option and the pros/cons of each.

Option 1 – Set ansible_python_interpreter: /usr/bin/python3 for hosts that have python3 installed by default

This is the option put forward in the official Ansible docs on Python 3 support. The docs suggest to set ansible_python_interpreter: /usr/bin/python3 for remote hosts that have Python 3 installed. Let’s test it out shall we?

Take a look at the result of running the following playbook against a fresh Ubuntu 18.04 instance:

– name:misc task on ubuntu 18.04 instancehosts:”*”tasks:- debug_var=ansible_host

We don’t even make it past the Gathering Facts task:

PLAY [misc task on ubuntu 18.04 instance]

TASK [Gathering Facts] fatal: [123.123.123.123]: FAILED! => {“changed”: false,
“module_stderr”: “/bin/sh: 1: /usr/bin/python: not foundn”,
“module_stdout”: “”, “msg”: “MODULE FAILUREnSee stdout/stderr for the exact error”,
“rc”: 127

Now let’s try again with ansible_python_interpreter: /usr/bin/python3:

– name:misc task on ubuntu 18.04 instancehosts:”*”vars:ansible_python_interpreter:/usr/bin/python3tasks:- debug_var=ansible_host

No errors this time:

PLAY [misc task on ubuntu 18.04 instance]

TASK [Gathering Facts] ok: [123.123.123.123]

TASK [debug] ok: [123.123.123.123]=> {“ansible_host”: “123.123.123.123”}

We can include this variable in a few ways:

• If all your remote hosts definitely have python3, you can just add the variable to your group_vars/all.yml file:

# group_vars/all.ymlansible_python_interpreter:/usr/bin/python3

• If you’re using dynamic inventory and some of your hosts don’t have python3 installed by default you could add tags that are read by your inventory script (e.g. ec2.py) and then apply the ansible_python_interpreter in a group_vars file based on the tag:

# group_vars/tag_OS_ubuntu1804.ymlansible_python_interpreter:/usr/bin/python3

• If you’re using static inventory and some of your hosts don’t have python3 installed by default you can add variables to groups in your inventory/hosts file:

[python2_hosts] centos7_server

[python3_hosts] u1804_server

[python3_hosts:vars] ansible_python_interpreter=/usr/bin/python3

Pros

The biggest advantage of this approach is that no changes are required on the remote hosts themselves, just a relatively minor change on the local host (and any tagging required).

Cons

The massive disadvantage of this approach is that you need to know in advance of running the playbook that the remote host definitely has Python 3 installed. If Python 3 isn’t available on the remote host, setting ansible_python_interpreter: /usr/bin/python3 will make your plays fail.

Setting tags or grouping your hosts by whether or not they have Python 3 could be a massive pain if you manage a lot of infrastructure.

Option 2 – Install Python 2 on a remote host using Ansible’s raw module

This solution entails creating a separate play with gather_facts: false and then use Ansible’s moduleraw to run commands on the remote host, bypassing all Ansible modules.

gather_facts: false will prevent Ansible from running the Gathering Facts task, which runs the modulesetup against the host.

Use of raw is highly discouraged and it should only really be used for special cases like this. Note that the raw module has no “change checking” – it will run every single time and is not idempotent unless the commands you’re running with it are themselves idempotent.

The commands we want to run with raw are what we would run on the host to get Python 2 installed:

sudo apt-get update
sudo apt-get -y install python

Let’s convert them into commands for raw in our new play:

– name:install python2 on ubuntu 18.04 instanceshosts:”*”gather_facts:falsetasks:- name:run apt-get update and install pythonraw:”{{ item }}”loop:- sudo apt-get update- sudo apt-get -y install pythonbecome:true- name:misc task on ubuntu 18.04 instancehosts:”*”tasks:- debug_var=ansible_host

The plays above should run successfully and give you output similar to this:

PLAY [install python2 on ubuntu 18.04 instances]

TASK [run apt-get update and install python] changed: [123.123.123.123]=> (item=sudo apt-get update)
changed: [123.123.123.123]=> (item=sudo apt-get -y install python)

PLAY [misc task on ubuntu 18.04 instance]

TASK [Gathering Facts] ok: [123.123.123.123]

TASK [debug] ok: [123.123.123.123]=> {“ansible_host”: “123.123.123.123”}

Notice the absence of the Gathering Facts task on the first play. The tasks in the second play succeed because Python 2 is now available.

Pros

Running this play at the top of a playbook means that we don’t have to set ansible_python_interpreter: /usr/bin/python3 for any of our remote hosts. We can adapt the play so that we can run it against all hosts and ignore failures if they don’t have apt-get by adding ignore_errors: true :

– name:install python2 on all instanceshosts:”*”gather_facts:falsetasks:- name:run apt-get update and install pythonraw:”{{ item }}”loop:- sudo apt-get update- sudo apt-get -y install pythonbecome:trueignore_errors:true

Cons

We need to add this extra play to the top of every playbook (or include it). This is a lot of needless repetition and adds a potential source of failure if we haven’t done it.

Since there is no change checking, it also means we need to run the play fully every time we run the playbook, which adds unnecessary extra time to run our playbooks.

Option 3 – Symlink /usr/bin/python -> /usr/bin/python3 using Ansible’s raw module

Another option in a similar vein to option 2 is to use the moduleraw to “symlink” /usr/bin/python -> /usr/bin/python3.

With a bit of shell magic, we can fashion a command to do this conditionally based on whether either of the files exist using conditionals:

if[ -f /usr/bin/python3 ]&&[ ! -f /usr/bin/python ]; then
ln –symbolic /usr/bin/python3 /usr/bin/python;
fi

This command says:

If /usr/bin/python3 exists and /usr/bin/pythondoes not exist then create a symbolic link /usr/bin/python -> /usr/bin/python3.

This makes the command flexible enough to run on all systems without any ignore_errors: true. For example, on a CentOS 7 system, the conditional will evaluate to false because /usr/bin/python3 does not exist.

In Ansible form:

– name:symlink /usr/bin/python -> /usr/bin/python3hosts:”*”gather_facts:falsetasks:- name:symlink /usr/bin/python -> /usr/bin/python3raw:|
if [ -f /usr/bin/python3 ] && [ ! -f /usr/bin/python ]; then
ln –symbolic /usr/bin/python3 /usr/bin/python;
fi
become: true
– name: misc task on all instances
hosts: “*”
tasks:
– debug: var=ansible_host

You should see the following output:

PLAY [symlink /usr/bin/python -> /usr/bin/python3]

TASK [symlink /usr/bin/python -> /usr/bin/python3] changed: [123.123.123.123]

PLAY [misc task on all instances]

TASK [Gathering Facts] ok: [123.123.123.123]

TASK [debug] ok: [123.123.123.123]=> {“ansible_host”: “123.123.123.123”}

Pros

Compared to option 2, this method is significantly faster and doesn’t require us to ignore errors. Also, using a conditional statement means that we create the symlink only if python3 exists and python doesn’t, which:

• prevents errors in the case python3 doesn’t exist
• prevents us from overriding python if it’s already installed

Cons

The only real downside of this method is that – like option 2 – we need to add or include this play at the top of all our playbooks, which adds unnecessary duplication and may be a source of errors.

Как в node.js на windows 10 запускать mp3 на фоне?

• 2 подписчика
• 14 часов назад
• 49 просмотров

ответа
2

• Node.js

Простой

Почему модули в nodeJS подключаются по разному?

• 1 подписчик
• 17 часов назад
• 31 просмотр

ответ
1

• Gulp.js

• +1 ещё

Средний

Как сделать адаптивный текст, адаптирующийся именно под размер блока?

• 1 подписчик
• вчера
• 71 просмотр

ответов
0

• Node.js

Простой

Conclusion and my recommendations

This is a really difficult one to call. Each option has advantages and disadvantages and the solution I recommend really depends on your situation.

To me, option 1 is generally superior because it doesn’t require changing your playbooks and doesn’t require changing the remote host in any way.

I think option 1 is the best solution if all your remote hosts are running a distro with Python 3 installed by default (e.g. Ubuntu 16.04 and up). It’s also the best solution if you’ve already tagged your infrastructure with the OS and OS version (e.g. AWS tags), or if you’re using static infrastructure and you’ve already grouped your servers by OS.

I think option 3 is the best solution if you are dealing with remote hosts that may not have Python 3 installed by default, or have no easy way to apply group_vars based on the OS. The reason this option wins out over option 2 is because it’s significantly faster and can run against any distro without any special error handling.

Know of any other ways to solve this problem? Please comment below and let me know what you think!

Как собрать БЭМ-проект с помощью Gulp?

• 1 подписчик
• 18 часов назад
• 21 просмотр

ответ
1

• Node.js

Простой

Как залить node js приложение на сервер?

• 1 подписчик
• 18 часов назад
• 38 просмотров

ответ
1

• Node.js

• +3 ещё

Простой

Ошибка после деплоя telegram бота на heroku?

• 1 подписчик
• 18 часов назад
• 5 просмотров

ответов
0

• Sass

• +1 ещё

Средний

2. Проверьте переменную среды PATH.

Каждый раз, когда вы, как пользователь, запускаете команду на своей консоли, машина ищет ее местоположение или адрес в списке предопределенных каталогов, которые хранятся в переменной среды PATH.

Такой дизайн помогает правильно запускать программу или команду без необходимости указывать абсолютный путь в терминале.

Переменная окружения PATH может быть изменен временно для текущего сеанса терминала, или на постоянной основе .

Чтобы отобразить содержимое переменной среды PATH на консоли:

$ echo $ PATH

Вывод:

:/usr/local/opt/ruby/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

Убедитесь, что установленный путь Python добавлен в переменную PATH. Вы можете видеть в приведенном выше выводе пути ‘/usr/bin’ и ‘/bin’ для python 3. Чтобы сделать его постоянным, обязательно экспортируйте переменную PATH в ~/.bash_profile или в соответствующий файл конфигурации, запускающий оболочку.