O que os scripts em /etc/profile.d fazem?

85

Estou lendo sobre scripts básicos de shell na Linux Command Line e na Shell Scripting Bible .

Ele diz que o /etc/profilearquivo define as variáveis ​​de ambiente na inicialização do shell Bash. O /etc/profile.ddiretório contém outros scripts que contêm arquivos de inicialização específicos do aplicativo, que também são executados no momento da inicialização pelo shell.

  • Por que esses arquivos não fazem parte /etc/profilese também são críticos para a inicialização do Bash?

  • Se esses arquivos são arquivos de inicialização específicos do aplicativo e não são críticos para a inicialização do Bash, por que eles fazem parte do processo de inicialização? Por que eles não são executados apenas quando os aplicativos específicos, para os quais contêm configurações, são executados?

asheeshr
fonte

Respostas:

71

Por que esses arquivos não fazem parte do / etc / profile se também são críticos para a inicialização do Bash?

Se você quer dizer "Por que eles não são combinados apenas em um script gigante?", A resposta é:

  1. Porque isso seria um pesadelo de manutenção para as pessoas responsáveis ​​pelos scripts.
  2. Como carregar os scripts como módulos independentes torna o sistema inteiro mais dinamicamente ajustável - scripts individuais podem ser adicionados e removidos sem afetar os outros. Etc.
  3. Porque eles são carregados via / etc / profile, o que os torna parte do "perfil" do bash da mesma maneira.

Se esses arquivos são arquivos de inicialização específicos do aplicativo e não são críticos para a inicialização do Bash, por que eles fazem parte do processo de inicialização? Por que eles não são executados apenas quando os aplicativos específicos, para os quais contêm configurações, são executados?

Isso me parece uma questão mais ampla de filosofia de design que vou dividir em duas. A primeira pergunta é sobre o valor e a adequação do uso do ambiente shell. Tem valor positivo? Sim, é útil. É a melhor solução para todos os problemas de configuração? Não, mas é muito eficiente para gerenciar parâmetros simples e também amplamente reconhecido e entendido. Em contraste, para dizer que, ao decidir configurar essas coisas de forma heterogênea, talvez o $ PATH possa ser gerenciado por uma ferramenta independente separada, as ferramentas preferidas, como o $ EDITOR, podem estar em um arquivo sqlite em algum lugar, e o material $ LC lang pode estar em um arquivo de texto com um formato personalizado em outro lugar, etc - não apenas usando variáveis ​​env e/etc/profile.dde repente parece mais simples? Você provavelmente já sabe o que é uma variável de ambiente, como eles funcionam e como usá-los, versus aprender 5 mecanismos completamente diferentes para 5 aspectos ubíquos diferentes do que é chamado apropriadamente de "ambiente".

A segunda pergunta é: "A inicialização é o momento apropriado para isso?", O que implora a objeção de que não é muito eficiente (todos os dados que podem ou não ser usados, etc). Mas:

  • Realisticamente, não são tantos dados, em parte porque ninguém em sã consciência os usaria para mais do que alguns parâmetros simples (já que existem outros meios de configurar um aplicativo).
  • Se for usado com sabedoria, no que diz respeito às coisas que normalmente são invocadas, a configuração, por exemplo, de $ CFLAGS padrão de um arquivo em algum lugar sempre que você invocar, gccseria menos eficiente. Lembre-se de que a quantidade de memória envolvida é novamente infinitesimal.
  • Pode envolver coisas sistêmicas nas quais mais de um aplicativo pode estar envolvido, e o shell é um terreno comum .

Mais poderia ser adicionado a essa lista, mas espero que isso lhe dê uma idéia dos prós e contras do problema - o principal 'profissional' e o principal 'con' sendo que é um espaço para nome global.

Cachinhos Dourados
fonte
Does it have positive ... and understood.O que você está tentando dizer aqui ? Eu entendi tudo além desse parágrafo.
asheeshr
3
O ambiente do shell geralmente é usado para configurar o próprio shell e outras ferramentas onipresentes. Essa não é a única maneira que a configuração pode ser feita; portanto, vale a pena considerar se o ambiente é melhor ou pior que as outras opções. Por ter "valor positivo", quis dizer que o uso do ambiente parece ter algumas vantagens sobre outras opções, pelo menos o WRT "gerenciando parâmetros simples" - a saber, que é muito eficiente e "amplamente reconhecido e compreendido" ... e eu vou adicionar um pouco para explicar mais essa frase.
9173 goldilocks
Que tal acrescentar linhas ao profile.local? Isso é aceitável versus a criação de scripts na pasta profile.d?
Avindra Goolcharan
@AvindraGoolcharan Distros diferentes podem usar esquemas diferentes para esse tipo de coisa. O profile.ddiretório funciona apenas porque seu conteúdo é originado por /etc/profile, que é especificado por shells como bash como um arquivo de inicialização (consulte INVOCATION in man bash); se você editar /etc/profile, poderá desativar /etc/profile.d. /etc/profile.localparece ser uma invenção do SUSE, presumivelmente proveniente de algum lugar, como /etc/profilepara que você possa colocar suas próprias coisas lá. No entanto, se você o mover para um sistema que não seja o SUSE e não fizer outros ajustes, ele não será usado por nada.
30914 goldilocks
Entendi, isso é claro. Sim, usamos o SUSE no meu trabalho. / etc / profile. parece uma aposta muito melhor.
Avindra Goolcharan
13

Esses arquivos são específicos para um aplicativo, mas são originados na inicialização do shell, não quando o aplicativo é iniciado. Um diretório de configuração é usado aqui pelo mesmo motivo que é encontrado em muitos outros lugares. Isso permite que um aplicativo ou pacote de software modifique as configurações. Isso não seria possível sem uma configuração dividida, pois vários pacotes que tentam gerenciar / atualizar um único arquivo de configuração que também pode ser modificado pelo usuário ficariam com erros e confusos.

Também uma nota lateral, /etc/profileé obtida por todas as conchas, não apenas pelo bash. O arquivo de configuração específico do bash é bashrc e é fornecido apenas para shells interativos.

jordanm
fonte
3
O segundo parágrafo é interessante. Como shells diferentes suportam sintaxe diferente, isso exigiria que houvesse uma sintaxe comum significativa. É verdade para bash e sh, mas acho que não para outros como csh ou tcsh, que possuem seus próprios scripts de inicialização de login global. Em muitos sistemas, / bin / sh é apenas um link para / bin / bash. Mas o bash modifica seu comportamento para ser compatível com posix quando chamado como sh. Então, alguém poderia pensar que os autores de scripts no /etc/profile.d precisariam ter cuidado para evitar o uso de extensões bash fora do subconjunto posix.
sootsnoot
No Linux, existem arquivos .csh e .sh separados para os dois principais tipos de shell.
Stark
0

A resposta de jordanm está incorreta. /etc/profilenão é obtido por todas as conchas. Como você ressalta, não é obtido por csh: tcsh- não tenho certeza zsh. É originário de shderivados Bourne shell ( ), como Korn Shell ( ksh) e BASH ( bash). cshusos /etc/login. Pessoas que tendem a usar exclusivamente derivados da Borne Shell tendem a esquecer que existem outras conchas. Eles acrescentam algo à /etc/profileexpectativa de que se aplique a "todos os usuários" e ficam surpresos quando o usuário estranho do C Shell (e nós somos um lote ímpar) não tem as coisas em que eles configuraram /etc/profile.

Mesmo assim, as pessoas tendem a esquecer outras conchas derivadas da Borne Shell. Se eles usam bashou ksh, sentem-se à vontade para adicionar uma sintaxe /etc/profileinválida no Bourne Shell, como, por exemplo, definir uma variável e exportá-la na mesma linha. Então você obtém um script que funciona #!/bin/she ele engasga com a sintaxe. /etc/profiledeve seguir a sintaxe compatível com Bourne Shell.

Da mesma forma, você deve cumpri-lo por conta própria .profile(use .bash_profilese quiser alguma sintaxe do bash) - pode ser uma digitação extra, mas é uma digitação extra que você faz todas as vezes. Referência ${HOME}e não ~, etc. Alguns sabores de Unix, tarefas agendadas executar sob sh, cada linha do seu Makefileé processado por sh, por isso, se você está trabalhando em vários sabores de UNIX, que realmente paga para manter seu .profileshell Bourne compatível. Como SysAdmin, não posso lhe dizer quantas vezes ajudei alguém a consertar .profileque ele fosse compatível com o Bourne Shell.

No Linux, /bin/shé um link para /bin/bashe quando você o executa, ele parece o caminho usado para executá-lo e (em teoria) se limita apenas a coisas que o Bourne Shell suporta. Da mesma forma, vino Linux está realmente vim, novamente se limitando. Ocasionalmente, você vê os recursos "sangrar". Ocasionalmente, vimfingir ser vifará algo que vimsuporta isso vinão porque os autores de vimesqueceram de desabilitar isso no modo "vi compatibilidade com versões anteriores". Eu não ficaria surpreso se bashfingir que shtem algumas características semelhantes de "sangrar". Não ficaria surpreso se algum recurso "funcionasse no Borne Shell no Linux", mas não em um UNIX baseado em System V ou BSD (AIX, OpenBSD, etc.).

Dâmocles
fonte
Você tem certeza de que "no Linux /bin/shhá um link para /bin/bash"? Essa é uma afirmação sólida.
41754 13/09