Когда вы просто присваиваете значение переменной, выражение $(...)
оценивается, если оно не заключено в одинарные кавычки (или в обратную кавычку). Чтобы понять, попробуйте сравнить эти два выражения:
A=$(pwd)
echo "$A"
B='$(pwd)'
echo "$B"
Значение A
немедленно становится строкой /home/yourusername
, и очевидно, что не запоминается, откуда взялась эта строка, она остается такой же, даже если вы смените каталог. Значение B
, однако, становится буквальной строкой $(pwd)
без интерпретации.
Теперь в значении PS1
происходит нечто особенное: всякий раз, когда выводится приглашение, интерпретируются некоторые специальные конструкции, например, подстановка команды $(...)
выполняется точно так же, как это произошло выше при присваивании переменной A
. Очевидно, что если ваша PS1
содержит литеральную строку вашего домашнего каталога (как выше в случае с A
), то она никак не может измениться. Но если он содержит строку $(pwd)
(как выше с B
), то она оценивается всякий раз, когда выводится приглашение, и, следовательно, отображается ваш реальный каталог.
Как предлагается в браузере предупреждений SELinux,
/sbin/restorecon -v /home/craig
должен решить проблемы.
Из AVC:
type = AVC msg = audit (1488394978.226: 257): avc: denied {search} for pid = 1426 comm = "login" name = "craig" dev = "dm-2" ino = 2621441 scontext = system_u: system_r: local_login_t: s0-s0: c0.c1023 tcontext = system_u: object_r: unlabeled_t: s0 tclass = dir permissive = 0
Вы можете прочитать, что ваш домашний каталог ( name = "craig"
) имел неправильную метку ( unlabeled_t
) вместо ожидаемого типа ( user_home_dir_t
на скриншоте). SELinux имеет MAC (обязательный контроль доступа) и логин
пытался сделать что-то, что не было разрешено политикой, это было запрещено.
Вероятно, это было вызвано манипуляциями с вашим домашним каталогом.