Por que as pessoas usam o bash_profile do bashrc ao invés do contrário?

7

Parece que a maioria dos emuladores de terminal não executam sessões locais como login por padrão, então eles carregam bashrc em vez de bash_profile. Então, por que a maioria das pessoas coloca tudo no bash_profile e tem a fonte bashrc ao invés do contrário? Por "maioria das pessoas" quero dizer a maioria das pessoas que vi até agora. Talvez não seja tão difundido quanto eu penso.

Em vez de colocar nossa configuração lá e ter bashrc source bash_profile, não faria mais sentido e seria mais consistente com a comunidade linux colocar tudo em bashrc e ter uma fonte bash_profile que?

Eu ouvi coisas boas sobre o iTerm2, e soa assim e quase todos os outros emuladores de terminal lá fora (além do Terminal OSX padrão) acabariam carregando o bashrc quando eu estou rodando localmente. Não que isso importe, contanto que alguém invente o outro, mas estou confuso porque preferir bash_profile é o padrão?

Menor nota: Eu estava enganado sobre o iTerm2. O padrão é executar sessões de login, assim como o Terminal.app, embora os dois emuladores pareçam ter uma opção que permite alterar isso.

    
por ivan 18.01.2014 / 05:46

3 respostas

10

Fonte de pessoas bash_profile de bashrc em vez do contrário devido à convenção local .

Toda a opinião que eu li sobre como alguém configura seus arquivos de inicialização em bash é baseada principalmente na convenção local. A convenção local geralmente não menciona o quadro geral em que não fala muito sobre o caso não-login, não interativo. O engraçado é, e eu olhei, mas eu raramente vejo alguém mencionar cron em toda a conversa sobre por que colocar variáveis em um arquivo de inicialização versus o outro. Na verdade, eu não ouvi um comentário dizer: " / bin / sh está lá por uma razão. Bash emula o shell original do Bourne, / bin / sh, quando invocado como tal. " Por um coisa, e eu discordo um pouco, este caso é importante para as pessoas que trabalham com o shell não só interativamente, mas que fornecem não-interativo, não-login ( sem supervisão ou background ) cron scripts que precisam de processamento mínimo de shell, isto é, o processamento de segundo plano não requer as sutilezas de prompts coloridos, histórico de comandos e substituição, uma variável $ TERM definida corretamente, etc.

Além disso, e em relação a cron , o que geralmente vejo são pessoas criando caminhos de pesquisa mínimos ou programas de chamada totalmente qualificados e não sabendo como lidar com a saída não conectada a um terminal (ou seja, login bash or sh case) ao trabalhar com seus scripts cron . Isso geralmente ocorre porque um bom entendimento da seqüência de inicialização do shell não é totalmente entendido, o que leva a que um usuário implemente seus próprios arquivos de inicialização de maneira inconsistente ou incoerente com as convenções já estabelecidas nos arquivos de inicialização /etc locais.

Elaborando, a configuração feita pela convenção local é mostrada naquela instalação específica e nos arquivos /etc do shell. Se alguém examina os arquivos /etc da instalação do UNIX, que são chamados como parte de uma sequência de inicialização típica bash , deve-se criar sua própria inicialização de maneira complementar à convenção estabelecida nesses /etc inicialização arquivos.

O Projeto de Documentação do Linux declara:

/etc/skel/ The default files for each new user are stored in this directory. Each time a new user is added, these skeleton files are copied into their home directory. An average system would have: .alias, .bash_profile, .bashrc and .cshrc files. Other files are left up to the system administrator.

Embora o manual bash não mencione esses arquivos que são comumente encontrados no diretório /etc/skel explicitamente, do que me lembro, SunOS, Solaris, RedHat, Ubuntu, HP-UX, umips & O Ultrix tem arquivos /etc/skel para padronizar os arquivos de inicialização do shell de um usuário depois. O OSX claramente não - estou usando o OSX 10.9.1 agora. Infelizmente, o OSX não lhe dá muito para explicar como as coisas devem ser configuradas em termos de convenção, mas como o OSX é um derivativo BSD, eu simplesmente usei outro derivativo BSD, e modelei minha própria seqüência de inicialização bash após ajustá-lo para caber nas convenções locais usadas nos arquivos de inicialização do OSX 10.9.1 /etc .

Um ponto importante que foi mencionado em um comentário paralelo é que, para o OSX, a convenção é iniciar cada novo Terminal como um shell de login interativo. Este é realmente o padrão no OSX. Não há nenhum problema com essa convenção, desde que os usuários de uma instalação sejam consistentes. O comportamento padrão do Terminal no OSX pode ser alterado para estar em conformidade com as convenções de inicialização do shell da distribuição UNIX fazendo as seguintes alterações nas preferências do Terminal , em particular, altere a configuração, Shells open with: para emitir o Comando /usr/bin/login -f -l whmcclos bash -i :

Comtudoissocomoplanodefundoouintrodução,vouseguirparameumelhorconselho,peloquevaleapena.

Meumelhorconselho:

ExamineosarquivosqueosadministradoresdesuadistribuiçãoUNIXimplementaram.Comececomosseguinteslocais,seexistirem.Nãoesqueçadeusarocomandols-a,porquealgunsdosarquivoscomeçamcomumponto.Vejacomoessesarquivossãousadosduranteainicializaçãoevejacomoseusprópriosarquivosdeinicializaçãointeragemcomeles:

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

Consulte o manual bash para a sequência de invocação e inicialização . Tudo está bem exposto.

Com tudo isso como uma ressalva - aqui está como eu fiz as coisas na minha instalação OSX 10.9.1 - Outras distribuições UNIX SERÃO diferentes, mas o que é apresentado abaixo deve funcionar na maioria das distribuições, se não todas, do UNIX, mas use essas outras Convenção de distribuições do UNIX como um guia para adaptar o abaixo para seus próprios propósitos:

.profile

# ~/.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/

Então são meus dois centavos. Tenha em mente que meus exemplos tentaram mostrar o caminho de controle através dos arquivos de inicialização e evitar o que as convenções de qualquer site em particular podem impor.

    
por 18.01.2014 / 17:44
4

why do we put everything in bash_profile in the first place?

.profile foi originalmente usado por / bin / sh, usando .profile para compatibilidade com versões anteriores.

A menos que você esteja usando o mac, tudo não será colocado no bash_profile. É colocado em bashrc

wouldn't it make more sense and be more consistent with the linux community to put everything in bashrc and have bash_profile source that?

É comum colocar informações do sistema no shell que é carregado quando você se conecta à máquina (tempo de atividade, pacotes que precisam de atualização, temp. cpu ...). Se bashrc sourced bash_profile, você veria todas essas informações toda vez que abrir um novo shell.

No Unix:

.bash_profile é carregado por shells de login
.bashrc é carregado por shells interativos

Com exceção do Mac, que carrega o shell de login para cada novo terminal (interativo ou não )

Recursos adicionais

diferença entre bashrc e bash-profile

Onde são variáveis de ambiente especificadas

    
por 18.01.2014 / 06:02
1

[...] I'm confused why preferring bash_profile is the standard?

Quem diz que é o padrão? O manual do Bash em si tem isto a dizer sobre o assunto:

So, typically, your ~/.bash_profile contains the line

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

after (or before) any login-specific initializations.

    
por 18.01.2014 / 06:46