我正在运行 autoconf 并将 SHELL 设置为“/bin/sh”。这会产生巨大的问题。如何强制 SHELL 成为 autoconf 的“/bin/bash”?
我试图让它在 osx 上运行,它在 linux 上运行。Linux 使用 SHELL=/bin/bash。osx 默认为 /bin/sh。
我在带有 GCC 的 Solaris 上遇到了类似的问题——我使用了“标准”技术:
CONFIG_SHELL=/bin/bash ./configure ...
(或者,实际上,我使用 /bin/ksh,但设置 CONFIG_SHELL 环境变量允许您告诉 autoconf 脚本使用哪个 shell。)
我检查了 git 和 gd 的配置脚本(它们恰好被提取)以检查这不是 GCC 特有的 env var。
什么是“大问题”?autoconf 非常努力地生成适用于很大比例 shell 的配置脚本。如果您有一个 autoconf 正在编写的不可移植的构造示例,请将其报告给 autoconf 邮件列表。另一方面,如果您遇到的问题是由于您自己在 configure.ac 中的 shell 代码不可移植(例如,您正在使用 bashisms),那么解决方案是停止使用不可移植代码或要求用户在配置时显式设置 SHELL 或 CONFIG_SHELL。
听起来您遇到的问题是在用户运行配置的环境中。在 Linux 上,您的用户将 SHELL 设置为 /bin/bash,但在 OS X 上,它设置为 /bin/sh。由 autoconf 生成的配置脚本会对其运行的 shell 进行一些初始测试,如果提供的 shell 缺少某些功能,它会尝试使用不同的 shell 重新执行自身。但是,如果您在 configure.ac 中引入不可移植的 shell 代码,那么您就违反了 autoconf 的主要理念之一——即配置脚本应该是可移植的。如果您真的想在您的 shell 代码中使用 bashism,那么您需要您的用户将 SHELL=/bin/bash 作为参数传递给配置脚本。这不是 autoconf 中的错误,但许多人会认为这是您项目构建中的错误。
Autoconf 应该通过生成可以“在任何地方”运行的脚本来解决可移植性问题。这就是为什么它会生成奇怪的代码,例如:
if test X$foo = X ; then ... # check if foo is empty
而不是:
if [ "$x" = "" ] ; then ...
那种笨拙的代码可能曾经允许这些脚本在一些古老的 Ultrix 系统或其他系统上运行。
由于外壳差异而无法运行的配置脚本就像带着 10 升汽油和三个备用轮胎参加一级方程式比赛。
如果您正在使用 Autoconf 开发配置脚本,并且它对 shell 是 Bash 还是 OSX shell 很敏感,那么您做错了什么,或者 Autoconf 的人破坏了某些东西。如果它来自您,请通过使它们可移植来修复您添加到脚本中的任何外壳片段。
SHELL 是在哪里设置的?当您需要 /bin/bash 时,使用 /bin/sh 运行什么?
配置脚本可以在任何地方运行,即使是在野外存在的严重损坏的非 Bash shell 上也是如此。
编辑:究竟是什么问题?
另一个编辑:也许您希望脚本重新执行自身,就像这样。这可能是错误的:
if test "$SHELL" = "/bin/sh" && test -x /bin/bash; then
exec /bin/bash -c "$0" "$@"
fi
ln -f /bin/bash /bin/sh
:-P(不,这不是一个严肃的答案。请不要这样做!)