Recientemente noté que tenemos 3 opciones para establecer variables de entorno:
export envVar1=1setenv envVar2=2env envVAr3=3Si hay otras formas, por favor, ilumínanos.
¿Cuándo debería preferir uno sobre el otro? Por favor sugiera pautas.
En cuanto a la compatibilidad de shell, ¿cuál es el más expansivo (cubre más dialectos de shell)?
Ya noté esta respuesta, pero deseo ampliar la pregunta envy las pautas de preferencia de uso.
Respuestas:
export VARIABLE_NAME='some value'es la manera de establecer una variable de entorno en cualquier shell POSIX-compatible ( sh, dash, bash, ksh, etc .; también zsh). Si la variable ya tiene un valor, puede usarla export VARIABLE_NAMEpara convertirla en una variable de entorno sin cambiar su valor.
Los shells Bourne anteriores a POSIX no admitían esto, por lo que verá scripts que se deben evitar export VARIABLE_NAME='some value'y usar VARIABLE_NAME='some value'; export VARIABLE_NAME. Pero los proyectiles Bourne pre-POSIX son extremadamente raros hoy en día.
setenv VARIABLE_NAME='some value'es la sintaxis de csh para establecer una variable de entorno. setenvno existe en sh, y csh es extremadamente raro en scripts y ha sido superado por bash para uso interactivo durante los últimos 20 años (y zsh por más tiempo), por lo que puede olvidarse de él a menos que lo encuentre.
El envcomando rara vez es útil, excepto en líneas shebang . Cuando se invoca sin argumentos, muestra el entorno, pero lo exporthace mejor (ordenado y a menudo citado para desambiguar nuevas líneas en valores de nuevas líneas que separan los valores). Cuando se invoca con argumentos, ejecuta un comando con variables de entorno adicionales, pero el mismo comando sin envtambién funciona (se VAR=value mycommandejecuta mycommandcon VARset to value, like like env VAR=value mycommand). La razón enves útil en la línea shebang es que realiza una PATHbúsqueda, y resulta que no hace nada más cuando se invoca con un nombre de comando. El envcomando puede ser útil para ejecutar un comando con solo unas pocas variables de entorno con-i, o sin parámetros para mostrar el entorno, incluidas variables con nombres no válidos que el shell no importa.
Establecer una variable como VAR='asdf'deja el entorno sin modificar, lo que significa que los programas que inicie en la misma sesión no sabrán nada VARy no podrán acceder a él. Desea este comportamiento al escribir scripts de shell.
export, por otro lado, es un bash incorporado que modifica el entorno haciendo que la variable exportada sea visible para los procesos secundarios generados en la sesión actual. Puede lograr lo mismo ejecutando VAR='asdf' %program_name%.
envNo es un programa incorporado, sino un programa en sí mismo. En la superficie funciona exactamente como cuando usted VAR='asdf' %program_name%, pero en el nivel inferior las cosas se ponen un poco más complicadas. Primero, se envpone en marcha. Modifica el entorno, luego ejecuta el comando con argumentos dados. El mismo comportamiento que puede lograr en su propio código utilizando la llamada al sistema exec (3) .
setenves solo exporten csh-family shells, como se indica en su respuesta.
Hay varias preguntas con respuestas que responden esto:
Diferencia entre las variables de shell que se exportan y las que no están en bash
¿Cuál es la diferencia en el uso entre las variables de shell y las variables de entorno?
(etc.)
VAR=asdfactualiza el entorno siVARya estaba en el entorno. (Esto no era cierto en el shell Bourne original)