bash – 以编程方式检测已安装的Common Lisp实现

这是一种相对常见的模式：你有一个bash脚本依赖于某个可用的可执行文件,它可能是可用的,但是在不同的位置,可能是用户拥有自己的编译版本和/或系统有几个替代方案.

我见过的方法归结为这个算法：

>如果有一个环境变量指定了可执行文件的完整路径,那么更喜欢它
>否则,如果用户主目录中有配置文件指定了位置,可能还有其他参数,则更喜欢这样
>否则,如果/ etc中有一个配置指定了位置,请要求系统软件包管理器列出与应用程序的典型安装名称匹配的软件包

前三个很容易使用bash测试函数实现,我猜,如果你到目前为止,你知道如何做到这一点. (如果没有,请问我会发布示例.)

这是第四点变得有趣.有两个变量需要处理.首先,确定已安装环境中的包管理器.这些并不缺乏,我已经看到了两种表方法(将OS映射到包管理器)和查询方法(寻找与rpm,yum,emerge等预期名称匹配的可执行文件).其次,确定适合您的包管理器的包名称.这也可能很棘手.一方面,您可能安全地遍历已知可执行文件列表并轻松查看列表.另一方面,无论具体实现如何,您的包管理器都可以提供通常提供服务的“虚拟”或“替代”包.例如,您可以grep port-tree for dev-lisp,并且可以合理地确定找到一个已安装的软件包.

最简单的情况是你的脚本要在少数众所周知的环境中运行：实现前三个中的一个或多个让用户覆盖脚本的自动选择,然后你的脚本自动选择只是迭代已知环境中的已知替代方案,直到找到它更喜欢的方式.

困难的情况是你必须支持多种环境.您最终编写了一个抽象层,它知道不同的可能的包管理器以及如何在通用级别或特定包中查询各种包的那些包系统.为在AIX,HP-UX,Solaris,几个Linux发行版和cygwin Windows上部署的脚本集完成此操作后,我可以说：不好玩.

在我阅读您的问题时,您将拥有一个脚本,该脚本将分发给您无法控制的环境的不同用户的计算机.这些目标机器的唯一要求是它们具有bash并且至少安装了一个Common LISP解释器.据此,我推断你无法安装任何装载机.但是,如果您可以安装,要求或检测其他答案中提到的任何发射器的存在,那肯定会节省大量工作.