Estaba intentando depurar mi script CGI que comenzaba con la línea:
#!/usr/bin/env python3
Por supuesto, el problema era que las variables de entorno (específicamente $PATH) de Apache HTTPd y mi shell eran diferentes.
Después de investigar un poco, descubrí que el nivel del sistema .profilepara el shell establece $PATHllamando a /usr/libexec/path_helper. Verifiqué esto llamando /usr/libexec/path_helpery comparando la salida con la salida de echo $PATH.
La ruta de Apache HTTPd es diferente a este valor. Esto me hace suponer que HTTPd establece el valor de $PATHmanualmente.
Mi pregunta es, ¿por qué? ¿Por qué un proceso se configuraría $PATHmanualmente? Supongo que /usr/libexec/path_helperes algún tipo de estándar del sistema, ¿no?
Entonces, la pregunta es, ¿por qué un proceso se configuraría $PATHmanualmente, en lugar de llamar a algún tipo de estándar a nivel de sistema, que /usr/libexec/path_helperparece un estándar a nivel de sistema?
Respuesta1
/usr/libexec/path_helperSólo lo he visto en Mac OS X; Los demonios (y también cron) en Unix generalmente no usan el mismo entorno (ni la misma configuración) que el shell, por lo que existe una división notable entre los shells interactivos (para los cuales Apple proporciona alguna configuración automática) y los demonios (especialmente aquellos no administrados). por Apple).
En realidad, podría ser muy malo si un demonio de red elige una nueva ruta porque algún usuario instaló algún paquete aleatorio para jugar y de repente el demonio de red llama a la herramienta equivocada desde la ruta equivocada... o tal vez el demonio de red necesita una versión específica del software X, no la del sistema de ruta de todo el sistema...
(Por cierto, desactivo /usr/libexec/path_helpy configuro completamente PATHmanualmente en todas partes, pero más o menos sé en qué problemas me estoy metiendo al hacer las cosas de esa manera).