我正在运行autoconf并将SHELL设置为'/ bin / sh'。
这产生了巨大的问题。如何强制将SHELL设置为autoconf的'/ bin / bash'？

我正在尝试在osx上运行它，它正在linux上运行。 Linux正在使用SHELL = / bin / bash。 osx默认为/ bin / sh。

解决方案

ln -f / bin / bash / bin / sh`

:-P(不，这不是一个认真的答案。请不要通过这样做来破坏系统！)

SHELL设置在哪里？当我们需要/ bin / bash时，正在使用/ bin / sh运行什么？

configure脚本可以在任何地方运行，甚至可以在野外存在的极其破损且非Bash的外壳上运行。

编辑：到底是什么问题？

另一个编辑：也许我们希望脚本重新执行自身，就像这样。可能是越野车：

if test "$SHELL" = "/bin/sh" && test -x /bin/bash; then
    exec /bin/bash -c "
CONFIG_SHELL=/bin/bash ./configure ...
" "$@"
fi

我在带有GCC的Solaris上遇到类似的问题，并且使用了"标准"技术：

(或者，实际上，我使用/ bin / ksh，但是设置CONFIG_SHELL env var允许我们告诉autoconf脚本使用哪个shell。)

我检查了git和gd(它们刚好被提取)的配置脚本，以检查这不是GCC特有的env var。

什么是"巨大问题"？ autoconf非常努力地生成可与很大一部分外壳一起使用的配置脚本。如果我们有一个示例，说明autoconf正在编写的结构不可移植，请将其报告给autoconf邮件列表。另一方面，如果我们遇到的问题是由于configure.ac中我们自己的外壳代码不便于移植(例如，我们正在使用bashisms)导致的，则解决方案是停止使用非便携式代码或者要求用户在配置时显式设置SHELL或者CONFIG_SHELL。

听起来我们遇到的问题是在运行configure的用户环境中。在Linux上，用户的SHELL设置为/ bin / bash，但是在OS X上，用户的SHELL设置为/ bin / sh。由autoconf生成的configure脚本会对运行它的shell进行一些初始测试，如果提供的shell缺少某些功能，它会尝试使用其他shell重新执行自身。但是，如果在configure.ac中引入了不可移植的shell代码，那么我们将违反autoconf的主要原理之一-即，配置脚本应该可移植。如果我们确实想在shell代码中使用bashisms，则要求用户将SHELL = / bin / bash用作配置脚本的参数。这不是autoconf中的错误，但是许多人认为这是项目构建中的错误。