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

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?

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.

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.

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.).