使用shell脚本是不错的选择。我公司有一些5类软交换机，并且呼叫处理代码和供应接口是用Java编写的。其他所有内容都用KSH编写-数据库转储用于备份，修剪，日志文件轮换以及所有自动报告。我认为所有这些支持功能虽然与呼叫路径没有直接关系，但它们都是关键任务。特别是数据库交互。如果数据库交互代码出了点问题并转储了呼叫路由表，则可能使我们破产。
但是没有任何错误，因为Shell脚本是处理此类问题的理想语言。它们很小，很容易理解，处理文件是他们的强项，而且很稳定。并不是说KSH09会被完全重写，因为有人认为它应该编译为字节码，所以它是一个稳定的接口。坦白说，用Java编写的配置接口经常会出现不稳定现象，而且我记得的shell脚本从来没有弄乱。
[我认为这篇文章指出了不使用Shell脚本的原因的一个很好的清单-对于单个任务关键型项目符号，您指出的更多是基于所有其他项目符号的结论。
话虽如此，我认为您不想在shell脚本上构建关键任务应用程序的原因是，即使没有其他要点适用today，任何将要运行的应用程序在一段时间内保持下去将<<< [evolve到某个时候被这些潜在陷阱中的至少一个咬住的地步.....您实际上没有任何东西可以解决这个问题，而不必完全解决这个问题。...希望您从一开始就使用了更多的工业实力。
我可以轻松想象将外壳程序脚本放入航天器飞行软件中将是一个坏主意。但是Java或C ++可能是同样糟糕的选择。最佳选择是为此目的通常使用的任何语言（汇编语言）。
事实是，如果您使用任何类型的Unix，则在关键任务情况下都将使用Shell脚本，前提是您认为启动对于关键任务至关重要。当脚本需要做一些shell并不是特别擅长的事情时，您可以将这部分放入子程序中。您不会丢掉所有脚本。
我认为正确的答案是“取决于”。顺便说一句，对于是否应该将关键任务应用程序的已编译可执行文件放在信任中，这是一个相反的答案。
好的代码是好的，而坏的代码是不好的-无论是用Bash脚本，Windows CMD文件，以Python，Ruby，Perl，Basic，Forth，Ada，Pascal，Common Lisp，Cobol还是已编译的C语言编写的。
[[[这是
不是表示语言的选择无关紧要。有时候，有很好的理由选择特定的语言或进行编译与解释（性能，可伸缩性，功能，安全性等）。但是，在所有条件都相同的情况下，我相信一个伟大的程序员在一周的任何一天都可以使用由doofus编写的等效C ++程序编写的Shell脚本。
无论我们所有人都需要一个灵活的工具来与os进行交互。这是与我们使用的os的人类可读交互；就像用螺丝起子拧螺丝一样。命令行将永远是我们需要管理员，程序员或网络使用的工具。看看他们甚至在Powershell上扩展的窗口。