Если имеются ввиду стартовые скрипты (/etc/profile, /etc/profile.d/*, ~/.bash_profile, ~/.bashrc и т.д.), то нет. В man bash описан порядок, в котором они запускаются.

В этих скриптах переменная задана верно, но после перехода на openrc она задается не правильно, вот думаю что оно как-то ее меняет.

В смысле «после перехода на openrc»? Покажи $PATH до и после.

В смысле «после перехода на openrc»?

На debian решил потестировать экспериментальный openrc.

Было так:

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin

Стало так:

/usr/local/bin:/usr/bin:/bin:/usr/games

дык оба sbin вообще не должны быть в путях юзверя...

Ну дык в sysvinit и openrc разные стартовые скрипты. С чего ты взял, что именно в sysvinit они правильные? Во многих дистрах вообще убрали /usr/games, например, а /sbin и /usr/sbin есть только в рута.

В порядке вброса: systemd исправляет фрагментацию между дистрами именно в таких вещах.

Не должны, но мне удобнее набирать ifconfig, а не /sbin/ifconfig и т.п.

/etc/profile

if [ "$EUID" = "0" ] || [ "$USER" = "root" ] ; then
        PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:${ROOTPATH}"
else
        PATH="/usr/local/bin:/usr/bin:/bin:${PATH}"
fi
export PATH

# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin"
fi
export PATH

Есть такое и до перехода на openrc работало.

Если хочешь устанавливать глобально, поправь
/etc/env.d/00basic

Значит либо /etc/profile вообще не читается, либо openrc наново устанавливает PATH.

Если тебе так надо /sbin и /usr/sbin, добавь

export PATH="$PATH:/sbin:/usr/sbin"

В дебьяновском openrc нету /etc/env.d.

Интересно разобраться с чего такое произошло.

/etc/env.d/00basic

gentoo-way?

С того, что ты сменил sysvinit на openrc. Не благодари.

Если тебе так надо /sbin и /usr/sbin, добавь
export PATH=«$PATH:/sbin:/usr/sbin»
в ~/.bash_profile.

Тоже не работает

~/.bash_profile читается раз при входе пользователя. Перелогинься или сделай bash -l

Если просто перелогиниться не работает, если с bash - l то считывает.

Странно, попробуй тогда ~/.profile. Я вообще zsh пользуюсь, у меня ~/.zprofile, ~/.zlogin, ~/.zshenv и ~/.zshrc.

Там оно и так есть:

PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin"
if [ -n "$BASH_VERSION" ]; then
    # include .bashrc if it exists
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

Все должно работать, надо перезапустить пользовательскую сессию, ну или перезагрузиться.

Но не работает, помню подобная фигня была при переходе на wheezy(тогда и добавил ~/.profile, как советовали в баг-репорте)

но мне удобнее набирать ifconfig

ls -l /bin/ifconfig 
lrwxrwxrwx 1 root root 14 фев 16 04:25 /bin/ifconfig -> /sbin/ifconfig

Кажется, нашел что не так. Поменяй

PATH=...

export PATH=...

Есть-ли возможность узнать какой из скриптов последним изменял значение переменной(конкретно $PATH)?

нет. Разве что set -x во всех скриптах, а потом grep.

Есть-ли возможность узнать какой из скриптов последним изменял значение переменной(конкретно $PATH)?

Есть Unix-way.

берёш src пакет bash (ну либо sh)

патчиш интерпретатор в части присвоения переменых логированием в ...

компиляеш,подменяеш,узваеш,возвращаеш,ПРОФИТ

патчиш интерпретатор в части присвоения переменых

это называется «героически решаешь созданные тобой проблемы». К unix-way не имеет никакого отношения.

Сообщение удалено leave по причине 4.3 Провокация (-7)

Инициализация на баше - это просто и понятно.

это называется «решаеш проблему поставленную менеджером» - как решение дающее ожидаемую инфу( цель же задекларированна узнать как меняется некоторая внутряняя башевская переменная)- и в итоге получаем инстумент позволяющий отлаживать баш скрипты чуть легче ( можно пропатчить чтобы и трассу скидывал )

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

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

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

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

дык вроде у башей и прочих шелов существует режим трасировки - врубил , и дальше грепай-нехочу

а я об этом уже писал

Тоже не помогло

Инициализация на баше - это просто и понятно.

странная логика. В других ЯП лучше, да?

эт если мы предшестуем .

есть ли «set -x» на этапе старта всей «системы»?

и выставление PS4 и «дисплей ея» - в потоке смешаном с остальной диагностикой очень удобно для .

есть ли «set -x» на этапе старта всей «системы»?

нет, но это просто поправить пересобрав bash.

И да, проблема в том, что $PATH может любая программа переправить, не только bash.

в потоке смешаном с остальной диагностикой очень удобно для .

man grep.

Есть ещё префиксы. к примеру grep '^bash-debug: '

вот думаю что оно как-то ее меняет

strace еще не предлагали? Найдешь все файлы которые читает баш и грипни на предмет изменения переменной.

Ну тогда пропиши

export PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin"

Если и это не сработает, то у тебя сломан bash.

Если проблема не воспроизводится в виртуальной консоле: обычно de/wm читают ~/.xsessionrc (или ~/.xinitrc) в нем пользователь пишет ~/.profile. Можно посмотреть что в этих файлах, если не поможет - тогда нужно посмотреть где инициализируется de/wm.

Спасибо за наводку, ответ инашел здесь: .bash_profile Как он живет?

.xsession

if [ -f ~/.bash_profile ];
then . ~/.bash_profile
fi
exec awesome