Eu estava tentando depurar meu script CGI que começava com a linha:
#!/usr/bin/env python3
Claro, o problema era que as variáveis de ambiente (especificamente $PATH) do Apache HTTPd e do meu shell eram diferentes.
Depois de algumas pesquisas, descobri que o nível do sistema .profilepara o shell define o $PATHby call /usr/libexec/path_helper. Verifiquei isso chamando /usr/libexec/path_helpere comparando a saída com a saída de echo $PATH.
O caminho do Apache HTTPd é diferente deste valor. Isso me faz supor que o HTTPd define o valor $PATHmanualmente.
Minha pergunta é: por quê? Por que um processo seria definido $PATHmanualmente? Presumo que /usr/libexec/path_helperseja algum tipo de padrão de sistema, não?
Então, a questão é: por que um processo seria definido $PATHmanualmente, em vez de chamar algum tipo de padrão de nível de sistema, que /usr/libexec/path_helperparece ser um padrão de nível de sistema.
Responder1
/usr/libexec/path_helperSó vi no Mac OS X; daemons (e também cron) no unix normalmente não usam o mesmo ambiente (nem a mesma configuração) que o shell, então há uma divisão notável entre shells interativos (para os quais a Apple fornece alguma configuração automática) e daemons (especialmente aqueles não gerenciados pela Apple).
Na verdade, pode ser muito ruim se um daemon de rede escolher um novo caminho porque algum usuário instalou algum pacote aleatório para brincar e, de repente, o daemon de rede está chamando a ferramenta errada do caminho errado... ou talvez o daemon de rede precisa de uma versão específica do software X, não aquela do sistema de caminho de todo o sistema...
(A propósito, desativo completamente /usr/libexec/path_helpe configuro PATHmanualmente em todos os lugares, mas sei mais ou menos em que problema estou me metendo ao fazer as coisas dessa maneira.)