Si los procesos heredan el entorno de los padres, ¿por qué necesitamos exportar?

Leí aquí que el propósito de export en un shell es hacer que la variable esté disponible para los subprocesos iniciados desde el shell.

Sin embargo, también he leído aquí y aquí que “Los procesos heredan su entorno de su padre (el proceso que los inició)”.

Si este es el caso, ¿por qué necesitamos export? ? ¿Qué me estoy perdiendo?

¿Las variables de shell no forman parte del entorno de forma predeterminada? ¿Cuál es la diferencia?

Respuesta aceptada:

Su suposición es que las variables de shell están en el entorno . Esto es incorrecto. La export El comando es lo que define que un nombre esté en el entorno. Así:

a=1 b=2
export b

da como resultado el shell actual sabiendo que $a se expande a 1 y $b a 2, pero los subprocesos no sabrán nada sobre a porque no es parte del entorno (incluso en el shell actual).

Algunas herramientas útiles:

• set :Útil para ver los parámetros del shell actual, exportados o no
• set -k :Establece argumentos asignados en el ambiente. Considere f() { set -k; env; }; f a=1
• set -a :Le dice al shell que ponga cualquier nombre que se establezca en el entorno. Como poner export antes de cada tarea. Útil para .env archivos, como en set -a; . .env; set +a .
• export :Le dice al shell que ponga un nombre en el entorno. La exportación y la asignación son dos operaciones completamente diferentes.
• env :Como comando externo, env solo puede informarle sobre el heredado entorno, por lo tanto, es útil para comprobar la cordura.
• env -i :útil para limpiar el entorno antes de iniciar un subproceso.

Alternativas a export :

1. name=val command # La asignación antes del comando exporta ese nombre al comando.
2. declare/local -x name # Exporta el nombre, particularmente útil en funciones de shell cuando desea evitar exponer el nombre a un ámbito externo.
3. set -a # Exporta cada asignación siguiente.

Motivación

Entonces, ¿por qué los shells necesitan tener sus propias variables y un entorno diferente? Estoy seguro de que hay algunas razones históricas, pero creo que la razón principal es el alcance. El entorno es para subprocesos, pero hay muchas operaciones que puede realizar en el shell sin bifurcar un subproceso. Supongamos que hace un bucle:

for i in {0..50}; do
    somecommand
done

¿Por qué desperdiciar memoria para somecommand? incluyendo i , haciendo que su entorno sea más grande de lo que debe ser? ¿Qué sucede si el nombre de la variable que eligió en el shell significa algo no deseado para el programa? (Mis favoritos personales incluyen DEBUG y VERBOSE . Esos nombres se usan en todas partes y rara vez en espacios de nombres adecuados).

Relacionado:¿Qué significa esta salida de xev?

¿Qué es el medio ambiente sino el caparazón?

A veces, para comprender el comportamiento de Unix, debe observar las llamadas al sistema, la API básica para interactuar con el kernel y el sistema operativo. Aquí, estamos viendo el exec familia de llamadas, que es lo que usa el shell cuando crea un subproceso. Aquí hay una cita de la página de manual para exec(3) (énfasis mío):

El execle() y execvpe() Las funciones permiten a la persona que llama especificar el entorno del programa ejecutado a través del argumento envp. El argumento envp es una matriz de punteros a cadenas terminadas en nulo y debe terminar con un puntero NULL. Las otras funciones toman el entorno para la nueva imagen del proceso del entorno de la variable externa en el proceso de llamada.

Así que escribiendo export somename en el shell sería equivalente a copiar el nombre en el diccionario global environ en C. Pero asignando somename sin exportarlo sería como asignarlo en C, sin copiarlo al environ variables.