如何将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仅在子外壳中导出，但我也希望在我的父外壳中进行设置，因此在出现提示时，这些VAR仍正确设置。

我知道

. .myscript.sh

但是有没有“采购”的方法吗？因为我的用户经常忘记“来源”。

EDIT1：删除“ exit 0”部分-这只是我打字而没有先思考

EDIT2：添加更多有关我为什么需要这样做的详细信息：我的开发人员为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，并且我让他们（如上所述）提供文件源，以便他们可以来回切换ENV变量设置。（$ BIN应该一次指向$ ABC_BIN，然后我需要切换到$ BIN = $ DEF_BIN）

现在，脚本还应该为同一应用的并行开发创建新的沙箱，等等。这使我可以交互方式进行操作，询问沙箱名称等。

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

我考虑过的另一个选项是编写别名并将其添加到每个用户的个人资料中

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

并运行它

• setup_env parameter1 ... parameterX

现在对我来说更有意义

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

首先-由于结尾处的出口0，您不希望获取该脚本。

其次，没有任何Unix子进程可以直接更改父级的环境。否则，各种疯狂的事情都是可能的。

您可以使用默认的配置文件或bashrc文件向其环境中添加一些内容，还是可以为它们正在尝试运行的任何程序编写包装器？

请允许我详细介绍“包装”概念。

假设您要在环境变量“ OPTIONS”中使用PROD或DEV运行窥探程序，这取决于您是否要生产或开发。如果未设置，则可以说snoopy做一些奇怪的事情，例如擦除数据库以进行生产和开发...

将“ 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语句中具有二进制文件的完整路径...

答案是采购。源代码允许您将变量包括在当前 shell 的脚本中，但绝不能是其父级。的确，您必须小心不要使用任何退出命令或类似命令，因为那样会关闭您当前的外壳程序。

您可以使用“。”来获取脚本，即

。./myscript.ksh

也许如果您尝试...

#!/bin/bash

mknod fifo p

(
       echo 'value' > fifo &
)

VARIABLE=`cat fifo`
rm fifo

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

好吧，现在不要笑。非常快速和非常肮脏的解决方案是添加

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

到您的脚本。

另一种方法。只是exec一个下属$ SHELL脚本中的，也许有不同的提示（$改变PS1通知其下的环境，他们正在努力，以减少混乱的用户）。

另一种方法（我最喜欢的）。用户忘记了源代码脚本，为什么呢？采购恰恰是标准的做法。提醒他们的一种好方法是先删除第一行（#!/bin/sh），然后再删除chmod a-x它。此后仍可以获取它，但是显然不能错误地执行它。

兰特：总而言之，我觉得您最初有一个奇怪的想法。也许并不奇怪...我会说某种非Unix风格。我一生中从未需要将环境导出给父母。我曾经看到过类似的情况-login .profile询问为单个oracle帐户设置三种不同环境中的哪一种。坏主意，最后证明用户倾向于迁移到sudo（他们将sudo迁移到三个不同的oraxxx帐户）。如果我想问的话，你想达到什么目的？