Нет каталога /usr/local/bin в PATH

Потому что у рута могут быть свои файлы инициализации шелла.

Где их искать?

В домашнем каталоге, очевидно.

Может чего-то типа env-update сделать?

Смысл? Я ничего нигде не менял.

Что-то я ничего не понимаю:

avalon coding # env-update
>>> Regenerating /etc/ld.so.cache...
avalon coding # . /etc/profile
avalon coding # echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3:/usr/lib64/subversion/bin:/opt/vmware/bin:/opt/cuda/bin

Не нашёл ничего похожего.

Ну не знаю, grep -r PATH /etc/. Наверно что-то дистроспецифичное.

По этой команде нашёл вот что:

/etc/crontab:PATH=/sbin:/bin:/usr/sbin:/usr/bin

Может, оно?

Я всё равно не понимаю, почему у рута изначально куцый PATH, который расширяется только после . /etc/profile. Что за нафиг такой?

Нет, не оно.

у рута изначально куцый PATH, который расширяется только после . /etc/profile

su - -c и /etc/profile

/etc/profile копируется тебе в ~/.bashrc при создании нового пользователя. Либо должно быть там указано.

Кури свои ~/.bashrc и ~/.bash_profile

Оно же у всех поначалу куцее. Не?:

Что значит «у всех»? Как я тогда запускаю vmplayer?

Нет у рута в хомяке этих файлов.

давайте, не будем врать?

 When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the  file
       /etc/profile,  if  that  file exists.  After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and exe‐
       cutes commands from the first one that exists and is readable.  The --noprofile option may be used when the shell is started to inhibit this behavior.

В ~/.bashrc PATH настраиваешь. Не?

ты как под рут заходишь su? если - да, то ошибка в этом, т.к. su сохраняет и не перезагружает окружение, решение su -:

% su -
Password: 
qnikst ~ # echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3:/opt/cuda/bin
qnikst@qnikst [git:master].zsh % su
Password: 
qnikst .zsh # echo $PATH
/sbin:/bin:/usr/sbin:/usr/bin

Да, у меня как раз .37

Вот он — корень твоей проблемы. Это что ж за дистрибутив такой сраный?

Приму к сведению.

Ты лучше скажи, зачем руту в хомяке эти файлы?

Хм... Вот до чего доводят советы без подключения libastral.so

Я-то думал, ты su - пишешь всегда

Ну что, прогресс: четыре года я набирал su root, потом до меня дошло, что можно набирать просто su, а сейчас вот, спустя ещё три года, я узнал, что нужно набирать su -

:D

Ну, здрассти!

А где же ты будешь рутовские alias'ы и прочую шнягу прописывать?

Т.е. man su ты никогда не читал?

       -, -l, --login
              Starts the shell as login shell with an environment similar to a real login:

Когда нужно будет прописать - создам этот файл и пропишу.

Пояснения: при переходе в режим суперпользователя командой su происходит просто вызов командного интерпретатора с правами root. При этом значения переменных окружения, в частности $PATH, остается таким же, как у пользователя. То есть в переменной $PATH не окажется каталогов /sbin, /usr/sbin, и без указания полного имени будут недоступны команды route, lilo, mkswap и другие. Более того, переменная $HOME будет указывать на каталог пользователя, и все программы, запущенные в режиме суперпользователя, сохранят свои настройки с правами рута в каталоге пользователя, что в дальнейшем может вызвать проблемы.

Нет, не читал :D

СТОП! Но эти каталоги-то есть (см. стартовый пост)! Нет дополнительных каталогов (/usr/local/bin и т.д.). Почему?

это цитата из вики Альта, в разных дистрибутивах могут быть небольшие отличия, но принцип то везде один и тот же. Пиши лучше всегда с минусом и будет меньше проблем.

/usr/local/bin

Это вообще — извращение

Это удобно для складирования самописных скриптов. Не совать же их к остальным программам.

Для самописных скриптов есть ~/bin

И добавлять его в PATH? Бред.

~ % ls -l /usr/local/bin
lrwxrwxrwx 1 root root  16 авг.  25  2011 wgetpaste -> /usr/bin/lodgeit*
lrwxrwxrwx 1 root root  18 авг.  25  2011 xmessage -> /usr/bin/gxmessage*

есть идеи как сделать лучше?

ну и конечно тестирование приложений, которые надо ставить в систему для корректной работы.

Зачем? Просто закинь это в /etc/profile или куда-нибудь в /etc/profile.d/

Все равно юзерам придется делать PATH=PATH:~/bin

А на кой хрен такое творить?

Просто закинь это в /etc/profile или куда-нибудь в /etc/profile.d/

А это типа не то же самое, что и добавить в PATH?

Тогда не придется каждому юзеру самостоятельно это делать.

wgetpaste - просто полезность, можно было и алиасом поправить, а вот xmessage -> gxmessage, потому, что xmessage тормознутое говно, а у многих программ его вызов зашит, в итоге у меня вызывается полностью совместимый адекватный аналог. при этом system wide.

Я и не говорил про «самостоятельно».

И каждый юзер будет лазить в хомяк рута? Так у него прав не хватит. Или ты предлагаешь каждому юзеру создать каталог ~/bin и скопировать туда скрипты? Ну и зачем нужно такое дублирование?

И что, не вариант в общесистемные алиасы это запихать?

А в чём разница?

И каждый юзер будет лазить в хомяк рута?

Да ты не понял: я имею в виду, что у каждого юзера есть 100500 своих самописных скриптов и программулинок, которые он складывает себе в ~/bin. И ему приходится в ~/.bashrc прописывать добавление ~/bin к PATH. А ежели ты сделаешь это глобально, юзеру меньше головной боли.

Не надо ФС всяким говном засирать. И директории, которые 100 лет не сдались (/var/local) можно удалить на хрен.

нефиг чужие алиасы засорять.

я имею в виду, что у каждого юзера есть 100500 своих самописных скриптов и программулинок, которые он складывает себе в ~/bin

А если одному юзеру захочется воспользоваться скриптом другого пользователя? Будешь чехардить с правами доступа, лол?

Для этих целей есть совершенно удобный и пустой каталог /usr/local/bin. И ничего велосипедить не нужно.

Кому не надо — может unalias сделат.

А если одному юзеру захочется воспользоваться скриптом другого пользователя?

Если тот запретил доступ к хомяку — никак. И это правильно.

Для этих целей есть совершенно удобный и пустой каталог /usr/local/bin

И ты разрешаешь всем подряд туда писать? Вот же делать не хрен!