Quais são os prós e contras em usar o "-l" em um script shebang

Question

Recentemente cheguei a uma solução fácil para um problema crontab logging e estou me perguntando quais são os prós e contras de usar essa correção específica (executando um script com um "sinalizador de shell de login") , como:

#!/bin/bash -l 

    

Answer 1

[O seguinte pressupõe que seu "problema de registro" não especificado estava relacionado à configuração do ambiente ausente, normalmente herdada do seu perfil.]

A opção -l diz ao bash para ler todos os vários scripts de "perfil", a partir de /etc e do seu diretório pessoal. Normalmente, o Bash apenas faz isso para sessões interativas (nas quais o bash é executado sem nenhum parâmetro de linha de comando).

Os scripts normais não têm nenhum negócio lendo o perfil; eles devem funcionar no ambiente que receberam. Dito isso, talvez você queira fazer isso para scripts pessoais, talvez, se eles estiverem intimamente ligados ao seu ambiente e você planeja executá-los fora de uma sessão normal.

Um crontab é um exemplo de executar um script fora de sua sessão, então sim, vá em frente!

Se o script é puramente para o uso do crontab, então adicionar -l ao shebang é bom. Se você puder usar o script de outras maneiras, considere corrigir o problema do ambiente no próprio crontab:

0 * * * * bash -l hourly.sh

    

Answer 2

Honestamente, não vejo qualquer benefício em executar um script não interativo em um shell de login.

O shell de login analisará os arquivos de inicialização relevantes do shell de login ( bash usa ~/.bash_profile ) para configurar o ambiente da sessão do shell, etc.

Não é irracional acreditar que um usuário possa fazer todo tipo de coisas interessantes nesse arquivo, como iniciar tmux (como em esta questão ) ou mesmo executando exec em outro shell completamente (como em esta questão , < um href="https://unix.stackexchange.com/questions/46645/how-can-i-use-bash-as-my-login-shell-when-my-sysadmin-refuses-to-let-me- change-i "> e isso ).

Em vez disso, o ambiente em que o script precisa ser executado deve ser configurado no arquivo apontado por $BASH_ENV . Este arquivo será originado por qualquer shell bash não interativo.

Um script sendo executado a partir de uma tarefa cron não seria executado em um shell interativo nem em um shell de login e precisaria ser iniciado como

@daily    BASH_ENV="$HOME/script.env" "$HOME/script.sh"

(para um trabalho diário acionado à meia-noite) aqui $HOME/script.env pode ser $HOME/.bashrc se é onde o ambiente está configurado.