关于bash：我为什么不应该在shell脚本上“打赌公司的未来”？

我在看http://tldp.org/LDP/abs/html/why-shell.html并被以下内容震惊：

When not to use shell scripts

...

• Mission-critical applications upon which you are betting the future of the company

为什么不？

---

当您利用Shell脚本的优势时，可以使用它们。我公司有一些5类软交换机，并且呼叫处理代码和供应接口是用Java编写的。其他所有内容都用KSH编写-数据库转储用于备份，修剪，日志文件轮换以及所有自动报告。我认为所有这些支持功能虽然与呼叫路径没有直接关系，但它们都是关键任务。特别是数据库交互。如果DB交互代码出了点问题并转储了呼叫路由表，则可能使我们破产。

但是，任何事情都不会出错，因为shell脚本是处理此类问题的理想语言。它们很小，很容易理解，处理文件是他们的强项，而且很稳定。并不是说KSH09会被完全重写，因为有人认为它应该编译为字节码，所以它是一个稳定的接口。坦白说，用Java编写的配置界面经常出现不稳定现象，而且外壳脚本从未使我记忆犹新。

---

我认为这篇文章指出了不使用Shell脚本的原因的一个很好的列表-对于单个关键任务项目符号，您指出的更多是基于所有其他项目符号的结论。

话虽如此，我认为您不希望在Shell脚本上构建关键任务应用程序的原因是，即使今天没有其他要点适用，任何将在一段时间内维护的应用程序也会发展到某一时刻被这些潜在陷阱中的至少一个咬住的地步.....如果没有完整的解决方案，您真的无法做任何事情修复...。希望您从一开始就使用了更多的工业实力。

---

显然，这对我来说有些难为情。我真的很感兴趣为什么人们认为应该在"关键任务应用程序"中避免使用shell脚本，但是我无法想到一个令人信服的理由。

例如，我已经看到(并编写了)一些使用SQL * Plus与Oracle数据库进行交互的ksh脚本。可悲的是，由于查询未使用绑定变量，系统无法正确扩展。打击壳脚本，对吧？错误。问题不在于shell脚本，而在于SQL * Plus。实际上，当我用连接到数据库并使用绑定变量的Perl脚本替换SQL * Plus时，性能问题就消失了。

我可以轻易想象将外壳程序脚本放入航天器飞行软件中是一个坏主意。但是Java或C ++可能是同样糟糕的选择。最佳选择将是通常用于此目的的任何语言(汇编语言)。

事实是，如果您使用任何种类的Unix，则在关键任务情况下都将使用Shell脚本，前提是您认为启动对于关键任务至关重要。当脚本需要做一些shell并不是特别擅长的事情时，您可以将这部分放入子程序中。您不会大量抛弃脚本。

---

脚本只不过是计算机程序而已。有人会认为脚本不太复杂。这些人通常会承认您可以用脚本语言编写复杂的代码，但是从定义上看，这些脚本实际上不再是脚本，而是功能完善的程序。

随你。

我认为正确的答案是"取决于"。顺便说一句，这是对以下问题的相同答案：您是否应该信任任务关键型应用程序的已编译可执行文件。

好的代码是好的，坏的代码是不好的-无论是用Bash脚本，Windows CMD文件，用Python，Ruby，Perl，Basic，Forth，Ada，Pascal，Common Lisp，Cobol还是编译的C编写。

这并不是说语言选择无关紧要。有时候，有很好的理由选择一种特定的语言或进行编译与解释(性能，可伸缩性，功能，安全性等)。但是，在所有条件都相同的情况下，我相信一个伟大的程序员在一周的任何一天都可以使用由doofus编写的等效C ++程序编写的Shell脚本。

---

当我阅读此引用时，我将重点放在"应用程序"部分而不是"关键任务"部分。

我读这句话是说bash并不是为了编写应用程序，而是为了编写脚本。因此，可以肯定的是，您的应用程序可能包含一些内务处理脚本，但不要编写critical-business-logic.sh，因为另一种语言可能更适合这种情况。

---

可能是shell脚本有助于将公司带入未来。从编程的角度来看，我知道我会浪费很多时间来执行我委托给Shell脚本的重复性任务。例如，我知道命令行的大多数subversion命令，但是如果我可以将所有这些命令集中到一个脚本中，那么我可以随意触发，这样可以节省时间和精力。

就像其他一些人所说的那样，语言是一个因素。对于我短暂的不想记住的步骤和粘合程序，我完全信任我的shell脚本并依靠它们。这并不意味着我要建立一个在后端运行bash的网站，但是我肯定会使用bash / ksh / python / whatever来帮助我生成框架项目并管理打包和部署。

---

无论我们所有人都需要一个灵活的工具来与os进行交互。这是与我们使用的os的人类可读交互；就像用螺丝起子拧螺丝一样。命令行将永远是我们需要管理员，程序员或网络使用的工具。看看他们甚至在Powershell上扩展的窗口。

---

我敢打赌，作者表明他们对合格的wrt shell脚本的某些方面不满意。例如，谁单元测试BASH脚本。

另外，脚本与底层操作系统的耦合程度很高，这可能是负面的。

---

脚本不适用于实现某些关键任务功能，因为它们必须同时具有+ r和+ x权限才能运行。可执行文件仅需带有+ x。

脚本具有+ r的事实意味着用户可以复制该脚本，对其进行编辑/转换，然后执行其已编辑的Cuckoo's-Egg版本。

---