Почему в Ubuntu по умолчанию ~ / .profile источник ~ / .bashrc?


30

Вот содержимое акции, ~/.profileкоторая пришла с моим 13.10 (закомментированные строки удалены):

if [ -n "$BASH_VERSION" ]; then
    if [ -f "$HOME/.bashrc" ]; then
    . "$HOME/.bashrc"
    fi
fi

if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Это унаследовано от Debian, но почему Canonical решила оставить его? Насколько я знаю, это не стандартный способ * nix, и я видел различные системы, где этого не произошло, поэтому я предполагаю, что у них, должно быть, были на то веские причины. Это может привести к непредвиденному поведению при запуске оболочек входа в систему (например, при входе в систему на компьютере), когда пользователь не ожидал получить ~/.bashrcисточник.

Единственное преимущество, которое я могу придумать, - это не путать пользователя со многими файлами запуска, позволяя им редактировать .bashrcсамостоятельно и читать их независимо от типа оболочки. Это, однако, сомнительное преимущество, так как часто бывает полезно иметь разные настройки для входа в систему и для интерактивных оболочек, и это блокирует вас от этого. Кроме того, оболочки входа в систему очень часто не запускаются в графической среде, и это может вызвать ошибки, предупреждения и проблемы (о боже!) В зависимости от того, что вы установили в этих файлах.

Так почему же Ubuntu делает это, чего мне не хватает?


Почему бы -n "$BASH_VERSION"быть правдой за пределами Баш?
Эллиотт Фриш

@ElliottFrisch этого не будет. Мой вопрос: почему .profileисточник .bashrc, это не так во всех версиях Linux, и мне интересно, каково его обоснование.
Тердон

Похоже, что это реализовано в Debian Upstream .
Эллиот Фриш

@ElliottFrisch да, я подумал, что это не так, посмотрел и увидел, что пришло время редактировать мой комментарий. Тем не менее, это не относится к системе SuSe, к которой у меня есть доступ (хотя она есть и к CentOS), и, насколько я помню, это не относится к различным системам (RH, Fedoras, более ранняя версия Ubuntus). Поэтому мне интересно, почему.
Тердон

Ответы:


15

Это исходное решение от Debian. Обоснование этого объясняется в этом очень хорошем вики-посте , выдержка которого приведена ниже. Резюме сводится к тому, чтобы «гарантировать, что логины GUI и не GUI работают одинаково»:

Давайте возьмем xdm в качестве примера. Однажды Пьер возвращается из отпуска и обнаруживает, что его системный администратор установил xdm в систему Debian. Он просто входит в систему, и xdm читает его файл .xsession и запускает fluxbox. Кажется, все в порядке, пока он не получит сообщение об ошибке в неправильной локали! Поскольку он переопределяет переменную LANG в своем .bash_profile, а xdm никогда не читает .bash_profile, его переменная LANG теперь установлена ​​в en_US вместо fr_CA.

Теперь наивное решение этой проблемы состоит в том, что вместо запуска «xterm» он может настроить свой оконный менеджер на запуск «xterm -ls». Этот флаг сообщает xterm, что вместо запуска обычной оболочки следует запустить оболочку входа в систему. При такой настройке xterm порождает / bin / bash, но в вектор аргумента помещает «- / bin / bash» (или, может быть, «-bash»), поэтому bash действует как оболочка входа в систему. Это означает, что каждый раз, когда он открывает новый xterm, он будет читать / etc / profile и .bash_profile (встроенное поведение bash), а затем .bashrc (потому что .bash_profile говорит об этом). На первый взгляд может показаться, что это работает нормально - его точечные файлы не тяжелые, поэтому он даже не замечает задержки - но есть более тонкая проблема. Он также запускает веб-браузер прямо из меню Fluxbox, и веб-браузер наследует переменную LANG от fluxbox, который теперь настроен на неправильную локаль. Таким образом, хотя его xterms могут быть в порядке, и все, что запускается из его xterms, может быть в порядке, его веб-браузер по-прежнему предоставляет ему страницы в неправильной локали.

Итак, что является лучшим решением этой проблемы? Там действительно нет универсального. Лучше всего изменить файл .xsession так, чтобы он выглядел примерно так:

[ -r /etc/profile ] && source /etc/profile
[ -r ~/.bash_profile ] && source ~/.bash_profile
xmodmap -e 'keysym Super_R = Multi_key'
xterm &
exec fluxbox

Это заставляет оболочку, которая интерпретирует скрипт .xsession, читать в / etc / profile и .bash_profile, если они существуют и доступны для чтения, перед запуском xmodmap или xterm или «выходом» из оконного менеджера. Однако у этого подхода есть один потенциальный недостаток: в xdm оболочка, которая читает .xsession, работает без управляющего терминала. Если в / etc / profile или .bash_profile используются какие-либо команды, предполагающие наличие терминала (например, «fortune» или «stty»), эти команды могут завершиться с ошибкой. Это основная причина, почему xdm не читает эти файлы по умолчанию. Если вы собираетесь использовать этот подход, вы должны убедиться, что все команды в ваших «точечных файлах» безопасны для выполнения, когда нет терминала.


Я все еще думаю, что это не очень хорошая идея. Идеальным вариантом было бы убедиться, что менеджер дисплеев получит глобальный профиль (чек) и пользовательскую оболочку .profile. Теперь я знаю, почему у меня есть дублированные пути в некоторых переменных ...
Rmano

2

Это стандартное поведение Ubuntu, это ~/.bashrcфайл запуска на уровне пользователя для каждой интерактивной оболочки. Когда вы в основном открываете терминал, вы запускаете не входящую в систему интерактивную оболочку, которая считывает ~/.bashrcи ~/.bashrcполучает содержимое и экспортируется в текущую среду оболочки. Это помогает получить все свои пользовательские переменные и функции оболочки в текущей оболочке. Также вы можете найти такие строки

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

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

Это важно для обеспечения хорошего пользовательского опыта. Например , один может хранить прокси удостоверение в системе .bashrc, если она не получить ни один из источников терминальных приложений ( а именно , ping, wget, curl, и lynxт.д.) будет работать должным образом. Или вы должны предоставлять учетные данные прокси каждый раз, когда открываете терминал.

Кроме того, Ubuntu по умолчанию .bashrcсодержит много удобных для пользователя псевдонимов (для lsи grepдля вывода цветного вывода), много новых определений для различных переменных оболочки, что повышает удобство работы с пользователем.

Но в случае входа в систему через ssh или входа в виртуальную консоль , вы получаете интерактивную оболочку входа. Там файл инициализации оболочки есть ~/.profile. Следовательно, если вы не используете источник, ~/.bashrcвы пропустите все эти полезные настройки в вашем .bashrc. Вот почему ~/.profileисходный код Ubuntu по умолчанию~/.bashrc

Дело, чтобы избежать

  • Вы никогда не должны получать ~/.profileформу изнутри ~/.bashrcв то же время, когда ~/.bashrcее получают ~/.profile. Это создаст бесконечный цикл ситуации, и в результате ваш запрос терминала будет приостановлен, если вы не нажмете Ctrl+ C. В такой ситуации, если вы поставите строку в~/.bashrc
установить -x

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


Спасибо, это все правдивая и полезная информация. Это просто не отвечает на мой вопрос. Я знаком с различиями между логином и без логина. Мой вопрос: почему в системах Ubuntu есть .profileисточники .bashrc? SuSe Enterprise 10 этого не делает, равно как и ни одна из версий Fedora, которые я использовал, но это было много лет назад, я могу ошибаться. CentOS 5.8 делает как ни странно. Во всяком случае, вы видите мою точку зрения? Это выбор дизайна, и мне интересно, почему он был сделан.
Тердон

Я не использовал строго другие дистрибутивы Linux, которые вы назвали. Можете ли вы сказать мне, как они обрабатывают ситуации, такие как команды с псевдонимами в сеансе SSH, которые определены в .bashrcили в .bash_aliases. Например, у меня есть псевдоним lsкак ls --color=autoв моем, .bashrcи мой .bashrcбыл получен из моего .profile. Здесь я могу использовать псевдоним даже из ssh. Или я мог бы использовать прокси в сеансе SSH. Если я не получу источник .bashrcот .profileменя, я потеряю эти функции. Я думаю, что это все о лучшем пользовательском опыте.
Souravc

Они не, эти псевдонимы не будут работать. И да, источники .bashrcисправляют это. Но это также вызывает проблемы, я помню, как в первый раз, когда я использовал систему, которая имела такое поведение, я продолжал получать эти странные сообщения при обращении sshк нему, потому что я использовал xset b offв своем, .bashrcкоторый использовал для отключения звонка терминала, но только в системе X, так что давал сообщения об ошибках. Мне понадобилось много времени, чтобы понять, что происходит, так как я не думал, что .bashrcэто будет прочитано при запуске оболочки входа в систему. Мне просто интересно, есть ли официальное заявление по этому поводу.
Тердон

Я согласен. Я также столкнулся с некоторыми проблемами ранее . Но это в основном полезно и удобно для пользователя, если вы помните и избегаете нескольких особых случаев. Разве это не так :)
souravc

Да, для этого есть веские причины. Мне было просто любопытно, давал ли Canonical обоснование для того, чтобы сохранить это решение.
Тердон
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.