7

Похоже, что большинство эмуляторов терминала по умолчанию не запускают локальные сессии в качестве входа в систему, поэтому они будут загружать bashrc, а не bash_profile. Так почему же большинство людей помещают все в bash_profile и используют исходный код bashrc, а не наоборот? Под "большинством людей" я подразумеваю большинство людей, которых я видел до сих пор. Может быть, это не так широко распространено, как я думаю.

Вместо того, чтобы помещать нашу конфигурацию туда и иметь исходный код bashrc bash_profile, разве не будет более разумным и более последовательным с сообществом linux помещать все в bashrc и иметь исходный код bash_profile?

Я слышал хорошие вещи об iTerm2, и это звучит так, и почти все другие эмуляторы терминалов (кроме терминала OSX по умолчанию) в конечном итоге загружают bashrc, когда я работаю локально. Не то, чтобы это имело значение, если один источник другой, но я запутался, почему предпочтение отдается bash_profile?

Незначительное замечание: я ошибся насчет iTerm2. По умолчанию он запускает сеансы входа в систему, как Terminal.app, хотя оба эмулятора, кажется, имеют опцию, позволяющую вам это изменить.

3 ответа3

10

Люди источник bash_profile из Bashrc вместо наоборот из - за местную конвенцию.

Все мнения, которые я читал о том, как настраивать свои файлы запуска в bash основаны в основном на местных соглашениях. Местное соглашение обычно не упоминает общую картину в том смысле, что в нем мало говорится о случае отсутствия входа в систему, неинтерактивного взаимодействия. Забавно, и я посмотрел, но я редко вижу, чтобы кто-то упоминал cron во всех своих разговорах о том, почему помещать переменные в один файл запуска по сравнению с другим. На самом деле, я не слышал ни одного комментария: « /bin/sh существует по причине.Bash эмулирует оригинальную оболочку Bourne, /bin/sh, когда вызывается как таковая. «Во-первых, и я немного отступлю, этот случай важен для людей, которые работают с оболочкой не только в интерактивном режиме, но и предоставляют неинтерактивные, не входящие в систему (автоматические или фоновые) сценарии cron которые требуют минимальной обработки оболочки, т.е. фоновой обработки не требует тонких цветных приглашений, истории команд и подстановок, правильно определенной переменной $ TERM и т. д.

Далее, что касается cron , то, что я обычно вижу, это люди, создающие минимальные пути поиска или вызывающие программы полностью квалифицированными, и не знающие, как обращаться с выводом, не подключенным к терминалу (т. Е. Случай неинтерактивного, не входящего в систему bash или sh ) при работе со своими скриптами cron . Обычно это происходит из-за того, что хорошее понимание последовательности запуска оболочки не полностью понято, что приводит к тому, что пользователь реализует свои собственные файлы запуска способом, который не согласуется или не согласуется с соглашениями, уже установленными в локальных файлах запуска /etc

Что касается разработки, настройка, выполняемая в соответствии с местным соглашением, изложена в этой конкретной установке и файлах оболочки /etc Если кто-то проверяет какие-либо установочные файлы UNIX /etc , которые вызываются как часть типичной последовательности запуска bash , то следует создать их собственный запуск способом, который соответствует соглашению, установленному в этих файлах запуска /etc

Проект документации Linux гласит:

/etc/skel/ Файлы по умолчанию для каждого нового пользователя хранятся в этом каталоге. Каждый раз, когда добавляется новый пользователь, эти файлы скелета копируются в их домашнюю директорию. Средняя система будет иметь:.alias, .bash_profile, .bashrc и .cshrc файлы. Остальные файлы оставлены на усмотрение системного администратора.

Хотя в руководстве по bash не упоминаются эти файлы, которые обычно находятся в каталоге /etc/skel , насколько я помню, SunOS, Solaris, RedHat, Ubuntu, HP-UX, umips и Ultrix имеют файлы /etc/skel шаблон запуска файлов запуска оболочки пользователя после. OSX явно нет - я использую OSX 10.9.1 прямо сейчас. К сожалению, OSX не дает вам многого понять с точки зрения того, как все должно быть настроено с точки зрения соглашения, но, поскольку OSX является производной от BSD, я просто использовал другую производную от BSD и после этого создал собственную последовательность запуска bash , приспособив его к местным соглашениям, используемым в файлах запуска OSX 10.9.1 /etc

Важным моментом, который был упомянут в параллельном комментарии, является то, что для OSX принято запускать каждый новый терминал в качестве интерактивной оболочки входа в систему. Это действительно значение по умолчанию в OSX. Нет никаких проблем с этим соглашением, пока пользователи установки последовательны. Поведение по умолчанию для Терминала в OSX может быть изменено в соответствии с другими соглашениями о запуске оболочки дистрибутива UNIX, внеся следующие изменения в настройки Терминала, в частности, измените настройку, Shells open with: для выдачи /usr/bin/login -f -l whmcclos bash -i команда:

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

Мой лучший совет:

Изучите файлы, которые установили администраторы вашего дистрибутива UNIX. Начните со следующих мест, если они существуют. Не забудьте использовать команду ls -a , потому что некоторые файлы начинаются с точки. Посмотрите, как эти файлы используются во время запуска, и посмотрите, как ваши собственные файлы запуска взаимодействуют с ними:

/etc/bashrc
/etc/profile
/etc/skel/.bash_logout
/etc/skel/.bashrc
/etc/bash.bashrc
/etc/bash_completion

Посмотрите в руководстве по bash последовательность вызовов и запуска. Все очень хорошо продумано.

Со всем этим, как предостережение - вот как я поступил в своей установке OSX 10.9.1 - Другие дистрибутивы UNIX будут отличаться, но то, что представлено ниже, должно работать на большинстве, если не на всех дистрибутивах UNIX, но использовать эти другие дистрибутивы UNIX Конвенция в качестве руководства для адаптации ниже для ваших собственных целей:

.профиль

# ~/.profile: executed by the command interpreter for login shells.

# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.  Note, however, that we will have a ~/.bash_profile and it
# will simply source this file as a matter of course.

# See /usr/share/doc/bash/examples/startup-files for examples.
# The files are located in the bash-doc package.

# From here on out, I basically set up my PATH, LD_LIBRARY_PATH, and anything else I'd like
# global to running programs and how those programs find their libraries.  This is shared by
# `cron`, so we really don't want interactive stuff, here.  Also, I setup my environments
# for brew, macports, and fink here, essentially with setting PATH, and invocation of those
# package initialization file as in:

# Brew and locally compiled stuff:
export PATH=/usr/local/bin:$PATH
export PATH=/usr/local/sbin:$PATH

# The following line puts gnu utilities without the prefix "g" in the path
# i.e. tar/gtar:
export PATH=$PATH:/usr/local/Cellar/coreutils/8.21/libexec/gnubin

# MacPorts shoves stuff in /opt, so to get at that stuff...
export PATH=/opt/local/bin:$PATH
export PATH=/opt/local/sbin:$PATH

# Set up for using Fink, which lives in /sw:
[ -e /sw/bin/init.sh ] && . /sw/bin/init.sh

# My stuff:
export PATH=~/perl:$PATH
export PATH=~/bin:$PATH
export PATH=.:$PATH

.bashrc

# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# From here on out, I put in things that are meaningful to interactive shells, like aliases,
# `shopt` invocations, HISTORY control, terminal characteristics, PROMPT, etc.

.bash_profile

# ~/.bash_profile: executed by the command interpreter for login shells.

# Because of this file's existence, neither ~/.bash_login nor ~/.profile
# will be sourced.

# See /usr/share/doc/bash/examples/startup-files for examples.
# The files are located in the bash-doc package.

# Because ~/.profile isn't invoked if this files exists,
# we must source ~/.profile to get its settings:
if [ -r ~/.profile ]; then . ~/.profile; fi

# The following sources ~/.bashrc in the interactive login case,
# because .bashrc isn't sourced for interactive login shells:
case "$-" in *i*) if [ -r ~/.bashrc ]; then . ~/.bashrc; fi;; esac

# I'm still trying to wrap my head about what to put here.  A suggestion
# would be to put all the `bash` prompt coloring sequence functions as
# described on http://brettterpstra.com/2009/11/17/my-new-favorite-bash-prompt/

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

4

почему мы все сначала помещаем в bash_profile?

.profile изначально использовался /bin /sh, использование .profile обеспечивает обратную совместимость.

Если вы не используете Mac, все не помещается в bash_profile. Ставится в башрч

Разве не было бы более разумным и более последовательным с сообществом linux поместить все в bashrc и иметь исходный код bash_profile?

Обычно системная информация помещается в оболочку, которая загружается при подключении к машине (время работы, пакеты, нуждающиеся в обновлении, температура процессора ...). Если bashrc sourced bash_profile, вы будете видеть всю эту информацию каждый раз, когда открываете новую оболочку.

В Unix:

.bash_profile загружается оболочкой входа
.bashrc загружается интерактивными оболочками

За исключением Mac, который загружает оболочку входа в систему для каждого нового терминала (интерактивного или нет)

Дополнительные ресурсы

разница между bashrc и bash-профилем

Где указаны переменные среды

1

[...] Я запутался, почему предпочтение bash_profile является стандартом?

Кто сказал, что это стандарт? Само руководство по Bash имеет следующее:

Так что, как правило, ваш ~/.bash_profile содержит строку

если [-f ~/.bashrc]; затем . ~/.Bashrc; фи

после (или до) любых инициализаций, специфичных для входа в систему.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .