如何将VAR从子shell导出到父shell?

我有一个Korn shell脚本

#!/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 

现在这些VAR仅在一个子shell中导出,但是我希望它们也可以设置在我的父shell中,所以当我在提示符时,这些variables仍然可以正确设置。

我知道

 . .myscript.sh 

但有没有办法做到这一点,而不是'采购'? 因为我的用户经常忘记“来源”。


编辑1:删除“退出0”的一部分 – 这只是我打字没有先考虑

编辑2:添加更多的细节为什么我需要这个:我的开发人员编写代码(为了简单起见)2应用程序:ABC和DEF。 每个应用程序都由单独的用户usrabc和usrdef在生产环境中运行,因此已经为其应用程序设置了$ BIN,$ CFG,$ ORA_HOME等等。

所以

  • ABC的$ BIN = / opt / abc / bin#$ ABC_BIN在上面的脚本中
  • DEF的$ BIN = / opt / def / bin#$ DEF_BIN

等等

现在,开发人员可以在开发人员的帮助下,同时在自己的用户帐户“justin_case”下同时开发ABC和DEF,并且让他们获取文件(上图),以便他们可以来回切换ENVvariables设置。 ($ BIN应该一次指向$ ABC_BIN,然后我需要切换到$ BIN = $ DEF_BIN)

现在,脚本还应该为同一个应用程序的并行开发创build新的沙箱,这使得我可以交互地执行它,请求沙盒名称等。

  • /家庭/ justin_case / sandbox_abc_beta2
  • /家庭/ justin_case / sandbox_abc_r1
  • /家庭/ justin_case / sandbox_def_r1

我考虑的另一个select是编写别名,并将其添加到每个用户的configuration文件

  • 别名“setup_env =”。 .myscript.sh”

并运行它

  • setup_env parameter1 … parameterX

这对我来说现在更有意义了

我认为这是一个“不能做”的问题。

首先 – 由于最后的0出口,你不希望获取该脚本。

其次,unixsubprocess不能直接改变父进程的环境。 否则,各种疯狂的事情将是可能的。

你可以使用默认的configuration文件或bashrc文件添加一些东西到自己的环境中,或者你可以编写一个封装程序来处理它正在运行的程序吗?

请允许我详细说明“包装”概念。

比方说,你想运行程序监听与环境variables“OPTIONS”中的PROD或DEV取决于你想要生产还是开发。 如果它没有设置,让我们说,史努比做一些像捣毁生产和发展的数据库…

将“snoopy”重命名为snoopy.bin(或.snoopy.bin)

然后将脚本放在名为“snoopy”的相同位置,其中包含以下内容:

 #!/bin/sh export OPTIONS case "$OPTIONS" in PROD) ;; DEV) ;; *) OPTIONS=DEV ;; esac #the binary is actually named snoopy.bin exec "$0.bin" "$@" 

如果你不想把实际的文件弄糟,把这个脚本放在文件系统的某个地方,这个文件系统将在用户PATH中的实际监听程序之前,并且在脚本的exec语句中有一个完整的二进制path。

答案是采购。 Sourcing允许您在当前 shell中的脚本中包含variables,但从来不是其父项。 确实,你必须小心,不要使用任何退出命令或类似命令,因为这会closures你当前的shell。

你可以通过使用“。”来源脚本,即

。 ./myscript.ksh

也许如果你尝试…

 #!/bin/bash mknod fifo p ( echo 'value' > fifo & ) VARIABLE=`cat fifo` rm fifo 

它不是完全可变的导出,但它可以提供与父进程的基本通信。

好的,现在不要笑了。 非常快速和非常肮脏的解决scheme是添加

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

到你的脚本。

另一种方法 。 只要在你的脚本中exec一个下级$ SHELL,也许用不同的提示(改变$ PS1来通知用户在哪个环境下工作,以减less混淆)。

另一种方法 (我最喜欢的)。 用户忘记来源你的脚本,为什么呢? 采购正是标准的走向。 也许提醒他们的一个好方法是删除第一行( #!/bin/sh ),然后chmod ax它。 之后还可以采购,但显然不能被误解。

Rant :总而言之,我觉得你首先有一个奇怪的想法。 也许不奇怪…我会说在风格上有点非Unix。 我从来没有需要出口环境父母在我的生活中。 我曾经看到过类似的情况 – login.profile询问为单个oracle帐户设置三种不同环境中的哪一种。 糟糕的想法,最终,事实certificate,用户更喜欢迁移到sudo(他们sudo'd到三个不同的oraxxx帐户)。 如果我可以问,你想达到什么目的?