Каковы возможные причины ошибки command not found, кроме переменной PATH?
Исторически (на не -GNU unices )этого не было, или, по крайней мере, вручную проверялось, входите ли вы в группу под названием "wheel", разрешенную su. Версия GNU suне воспроизводила эту функциональность из-за идеологии RMS в отношении контроля доступа в то время :
Why GNU `su' does not support the `wheel' group
===============================================
(This section is by Richard Stallman.)
Sometimes a few of the users try to hold total power over all the
rest. For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else. (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)
However, occasionally the rulers do tell someone. Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest. The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.
I'm on the side of the masses, not that of the rulers. If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.
Вы можете найти гораздо больше информации по этому вопросу, погуглив "wheel group rms" или что-то подобное.
Я думаю, что причиной являются контейнеры, как предположил @polemon в своем комментарии. (Для получения дополнительной информации см.:https://www.redhat.com/en/topics/containers/whats-a-linux-container)
Это потому, что я установил vscode через flatpak, который использует контейнер для запуска своих приложений.
Спасибо всем, кто внес свой вклад и помог внести ясность.
Как ни странно, я столкнулся с тем, что новая команда не была найдена после установки нового пакета в одной чрезмерно -настроенной среде zsh (с о -мой -zsh ). Я могу подтвердить, что это не поведение по умолчанию в zsh. По-видимому, в zsh есть «кеш» доступных команд, который можно настроить так, чтобы он не обновлялся автоматически -.
Какой-то тупой рисер думает, что разумно охранять этот путь -при -состоянии nfs или ram -голодном -состоянии системы на общих основаниях. Я не люблю о -мой -zsh и все эти причудливые -стили/конфигурации подсказок, которые люди устанавливают и восторгаются ими. Чертов хайп.
Думаю, здесь есть ответ на ваш вопрос:
Make sure you haven't unset the hash_list_all (...)
zstyle ":completion:*:commands" rehash 1
В моем случае я могу проверить указанную выше опцию, следуя инструкциям из этого ответа:
$ unsetopt | grep hash; echo ---; setopt | grep hash
nohashcmds
nohashdirs
hashexecutablesonly
nohashlistall
---
Другая возможность заключается в том, что среда очищается/инициализируется не так, как вы ожидаете от IDE. Однако кажется странным, что /usr/bin не будет в PATH. Создайте новый скрипт, запустите его из IDE и просто распечатайте среду, чтобы подтвердить свои предположения:
env > /tmp/env-in-script-from-ide
Ваше окружение испорчено.
Запустите следующее из внутреннего терминала и убедитесь, что вывод (вам не нужно обрезать вывод пути с помощью заголовка ). Используйте pdflatex вместо gzip или попробуйте оба варианта. Если вывод отличается в вашем обычном терминале и терминале визуального кода, это потому, что среда отличается.
Я предполагаю, что вы установили визуальный код через Snap, который имеет ограниченную или изолированную среду.
$ env | grep ^PATH= | tr : \\n | head -n 3; echo; which gzip; gzip --version | head -n1 ; echo $SHELL
PATH=vendor/bin
node_modules/.bin
/home/jaroslav/bin
/bin/gzip
gzip 1.10
/bin/bash
В моей среде это работает безупречно. Вывод идентичен в терминале визуального кода и в urxvt.
$ env | grep ^PATH= | tr : \\n | head -n 3; echo; which pdflatex; pdflatex --version | head -n1 ; echo $SHELL
PATH=vendor/bin
node_modules/.bin
/home/jaroslav/bin
/usr/bin/pdflatex
pdfTeX 3.141592653-2.6-1.40.22 (TeX Live 2021 Gentoo Linux)
/bin/bash
pdflatex
gzip
urxvt