Pelo que entendi, um daemon é um processo em segundo plano, mas o daemon requer um arquivo de configuração exclusivo para definir a variável de ambiente.
Por exemplo, o daemon do Hadoop requer hadoop-env.sh para definir a variável de ambiente JAVA_HOME
, você não pode simplesmente obter a variável de ~/.bashrc
.
O motivo é porque o daemon como um processo em segundo plano significa que não é interativo, enquanto ~/.bashrc é usado apenas em sessões interativas, para evitar alias cp='cp -i'
casos .
E o mais recente ~/.bashrc
tem o safe guard em cima do arquivo não permite chamador não interativo, ou seja, sem -i
opção retornará antes:
# ~/.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
case $- in
*i*) ;;
*) return;;
esac
Isso me faz pensar por que o bashrc não divide os arquivos de configuração em 3 grupos, como:
~/.bashrc_interactive
~/.bashrc_non_interactive
~/.bashrc_global #(interativo e não interativo)
Portanto, o usuário pode simplesmente definir ou JAVA_HOME
, e não há necessidade de adicionar essa variável de ambiente em cada arquivo daemon repetidamente.~/.bashrc_non_interactive
~/.bashrc_global
Existe alguma razão ou restrição de por que o bashrc não suporta não interativo dessa maneira ou de qualquer outra maneira? OU estou entendendo mal alguns conceitos?
A função de concepção do
~/.bashrc
arquivo é iniciar corretamente qualquer shell que seja:Claramente, a função desse script de shell é iniciar o ambiente que deve ser alterado em todos os níveis do shell, por exemplo
PS1
.Não é adequado para definir uma sessão ou um ambiente de daemon.
Existem outros scripts de shell que são dedicados a esse uso.
Para sessões interativas,
bash
procurará arquivos de inicialização nesta ordem:/etc/profile
~/.bash_profile
~/.bash_login
~/.profile
Para sessões não interativas, por exemplo, para iniciar um daemon,
bash
não use nenhum dos arquivos acima, mas leve em consideração a variável dedicadaBASH_ENV
(consulte a resposta de Kusalananda ).Você já tem a oportunidade de definir
BASH_ENV
o nome do caminho de um arquivo que o shell script não interativo analisa antes de executar.Isso permite que você faça, em um crontab por exemplo
ou mesmo
$BASH_ENV
geralmente está vazio, mas não há nada que o impeça de configurá-lo globalmente em seu servidor, apontando-o para um arquivo em/etc
queNo entanto, se um script precisar de variáveis específicas definidas, como
JAVA_HOME
etc., pode ser uma ideia melhor definirBASH_ENV
explicitamente um script por script, ou obter explicitamente o arquivo relevante de dentro do próprio script ou apenas definir o variáveis no script. Coletar todas as coisas que qualquer shell não interativo pode querer usar em um único arquivo pode desacelerar os scripts e potencialmente também poluir o ambiente dos scripts com coisas que eles não precisam.