为什么要为单个任务使用多种类型的 shell？答案

【问题标题】：Why use more than one type of shell for a single task?为什么要为单个任务使用多种类型的 shell？
【发布时间】：2019-03-10 11:44:50
【问题描述】：

我对高性能计算还很陌生，并且我继承了一些用于我正在处理的任务的现有代码。就目前而言，我有一个基于 Linux 的 HPC，它使用 MPI 和 PBS 来排队和运行作业。我继承的是 python 脚本，它动态构建并提交一个 PBS 脚本到队列，但是在单个作业的过程中，.sh、.csh 和 .ksh 脚本在不同的点被调用，并且大多数 shell 脚本都是非常简单，通常不到 10 行。在一个工作中使用多种不同的 shell 风格有什么好处吗？有什么明显的理由我不应该将它们全部转换为单一风味吗？

【问题讨论】：

这个问题很难回答。一般来说，如果脚本很简单，我认为值得将它们全部转换为一种语言。没有看到脚本很难肯定地说，这就是为什么我投票以“主要基于意见”来结束这个问题。
除非你能告诉我们这可能属于Software Engineering的代码。为任何任务使用多种语言的主要（唯一？）原因是它们各自擅长解决该任务的不同部分。这在 shell 脚本的情况下似乎不太可能，而且这种情况很可能是一个历史事故。
@l0b0 公平点。代码既庞大又混乱。在这里分享一些可以理解的东西是不可行的，但我怀疑你是对的。我的感觉是，这是经过多次迭代和开发人员拼凑而成的。我去那边提问题，看看有没有什么想法。
根据我的经验，使用不同的 shell 没有好的技术原因，但通常有非技术原因。一个是“黑盒”综合症，如果一个程序做你想做的事，为什么要重写它？不同的人对不同的贝壳有一种迷恋。我是在 csh 上长大的，纯粹是因为它是 Sun 的默认设置（编写 csh 的人创立了 Sun），幸运的是我很久以前就痊愈了。 ksh 要好得多，但直到（我认为）2000 年才开源，因此在 Linux 上使用了 bash。所以不同语言的原因可能是历史原因。
如果您决定转换它们，我建议您首先以独立于语言的方式记录它们的一般操作。然后使用文档编写新代码，逐行转换很少是一个好主意。还要考虑一个使用更强大的语言（如 python）的脚本更少的系统。然而，请永远记住这句格言如果它没有坏，就不要修复它。

标签： linux bash ksh csh

【解决方案1】：

在一个作业中使用多种不同的 shell 风格有什么好处吗？

极不可能。

这些 shell 之间的主要区别，尤其是在这种规模下，将仅仅是它们的语法。特别是，csh 对if 和for 等某些控制结构使用更“类似C”的语法； ksh 将更类似于您可能熟悉的 Bash 语法。它们的功能集基本相同。

使用这些解释器的最可能原因很简单：脚本是很久以前由不同的作者编写的，当时还没有围绕使用 Bash shell 达成共识。（如果年龄足够大，甚至可能 Bash 在当时并不存在——csh 和 ksh 在 1978 年和 1983 年发布，而 Bash 直到 1989 年才出现。）

【讨论】：

性能可能会有很大的不同——真正的 David Korn ksh93（与它的各种克隆不同）比 bash 执行速度快远（并且在一个 base-10 的顺序内） awk 的大小）。但是，如果您要混合语言以避免在慢速外壳中实现紧密的内部循环，为什么不采用 10 倍的性能差异并使用 awk，或者使用更快/更现代的语言，如 Go 或 Julia ? :)
（...也就是说，我永远不会建议任何人使用 csh；它对困扰 PHP 的良好设计有着同样的疏忽）。
...此外，直到 bash 4.x（它已经非常有效地缩小了差距），ksh93 在特性方面具有显着的领先优势——关联数组、名称变量等；我可以想到很多与性能无关的原因，我更喜欢 ksh93 而不是 4.0 之前的 bash。
@CharlesDuffy 请记住，这是在几个“通常少于 10 行”的脚本的上下文中。我怀疑速度或功能是这里的主要考虑因素！
浮点也可能是一个问题，即使在一个小脚本中也是如此。 ksh93支持浮点，其他不支持。