☰

¿Cómo exportar VAR desde un subshell a un shell principal?

tag-icon • tag-icon unix shell environment-variables
¿Cómo exportar VAR desde un subshell a un shell principal?

Tengo un script de shell Korn

#!/bin/ksh
# set the right ENV
case $INPUT in
abc)
  export BIN=${ABC_BIN}
  ;;
  def)
  export BIN=${DEF_BIN}
  ;;
  *)
  export BIN=${BASE_BIN}
  ;;
esac
# exit 0 <- bad idea for sourcing the file

ahora estos VAR se exportan solo en un subshell, pero quiero que también se configuren en mi shell principal, de modo que cuando aparezca el mensaje, esos vars todavía estén configurados correctamente.

Se acerca de

. .myscript.sh

pero ¿hay alguna manera de hacerlo sin "abastecimiento"? ya que mis usuarios a menudo olvidan "obtener".

EDITAR 1: eliminar la parte "salida 0"; solo era yo escribiendo sin pensar primero

EDITAR2: para agregar más detalles sobre por qué necesito esto: mis desarrolladores escriben código para (por simplicidad) 2 aplicaciones: ABC y DEF. cada aplicación se ejecuta en producción por usuarios separados usrabc y usrdef, por lo tanto, ha configurado su $BIN, $CFG, $ORA_HOME, lo que sea, específico para sus aplicaciones.

entonces

  • $BIN de ABC = /opt/abc/bin # $ABC_BIN en el script anterior
  • $BIN de DEF = /opt/def/bin # $DEF_BIN

etc.

ahora, en el cuadro de desarrollo, los desarrolladores pueden desarrollar ABC y DEF al mismo tiempo bajo su propia cuenta de usuario 'justin_case', y les hago obtener el archivo (arriba) para que puedan cambiar su configuración de ENV var de un lado a otro. ($BIN debería apuntar a $ABC_BIN al mismo tiempo y luego necesito cambiar a $BIN=$DEF_BIN)

ahora, el script también debería crear nuevos entornos sandbox para el desarrollo paralelo de la misma aplicación, etc. esto me obliga a hacerlo de forma interactiva, preguntando el nombre del sandbox, etc.

  • /inicio/justin_case/sandbox_abc_beta2
  • /home/justin_case/sandbox_abc_r1
  • /home/justin_case/sandbox_def_r1

La otra opción que he considerado es escribir alias y agregarlos al perfil de cada usuario.

  • alias 'setup_env=. .miscript.sh'

y ejecutarlo con

  • setup_env parámetro1 ... parámetroX

esto tiene más sentido para mí ahora

Respuesta1

Creo que es un problema del tipo "no se puede hacer"...

Primero, no querrás obtener ese script debido a la salida 0 al final.

En segundo lugar, ningún proceso hijo de Unix puede cambiar directamente el entorno del padre. De lo contrario, serían posibles todo tipo de locuras.

¿Podría agregar algo a su entorno con el perfil predeterminado o los archivos bashrc, o podría escribir un contenedor para cualquier programa que estén intentando ejecutar?

Permítanme profundizar en el concepto de "envoltorio".

Digamos que desea ejecutar el programa snoopy con PROD o DEV en la variable de entorno "OPCIONES" dependiendo de si desea producción o desarrollo. SI no está configurado, digamos que Snoopy hace algo estrafalario como borrar la base de datos para producción y desarrollo...

cambie el nombre de "snoopy" a snoopy.bin (o .snoopy.bin)

luego coloque un script en esa misma ubicación llamado "snoopy" que contenga esto:

#!/bin/sh

export OPTIONS

case "$OPTIONS" 
in
  PROD) ;;
  DEV) ;;
  *) OPTIONS=DEV ;;
esac

#the binary is actually named snoopy.bin 

exec "$0.bin" "$@"

Si no desea alterar el archivo real, coloque este script en algún lugar del sistema de archivos que esté por delante del programa snoopy real en la RUTA del usuario y tenga una ruta completa al binario en la declaración ejecutiva del script...

Respuesta2

La respuesta es el abastecimiento. Sourcing le permite incluir variables en un script en elactualshell, pero nunca un padre de eso. Es cierto, debes tener cuidado de no utilizar ningún comando de salida o similar, porque eso cerraría tu shell actual.

Puede obtener un script utilizando ".", es decir

. ./miscript.ksh

Respuesta3

Quizás si lo intentas...

#!/bin/bash

mknod fifo p

(
       echo 'value' > fifo &
)

VARIABLE=`cat fifo`
rm fifo

No es exactamente una exportación de variables, pero puede proporcionar una comunicación básica con el proceso principal.

Respuesta4

Vale, no te rías ahora. Una solución muy rápida y muy sucia es añadir

echo "Please copy and paste this command:"
echo ""
echo "export BIN=\"$BIN\""

a tu guión.

Otro enfoque. Solo execun $SHELL subordinado en su script, tal vez con un mensaje diferente (cambie $PS1 para notificar a los usuarios en qué entorno están trabajando para reducir la confusión).

Otro enfoque(mi favorito). Los usuarios olvidan obtener su script, ¿a qué se debe? El abastecimiento es precisamente el camino estándar a seguir. Quizás una buena forma de recordárselo sea eliminar la primera línea ( #!/bin/sh) y luego chmod a-xesa. Aún se puede obtener después de eso, pero obviamente no se puede ejecutar por error.

Despotricar: Considerándolo todo, siento que has tenido una idea extraña en primer lugar. Quizás no sea extraño... Yo diría que no tiene un estilo Unix. Nunca en mi vida he necesitado exportar el entorno a los padres. Una vez vi una situación similar: inicie sesión en .profile preguntando cuál de los tres entornos diferentes configurar para una sola cuenta de Oracle. Mala idea, al final resultó que los usuarios prefirieron migrar a sudo (hicieron sudo a tres cuentas oraxxx diferentes). ¿Qué estás tratando de lograr, si se me permite preguntar?

información relacionada