为什么我不应该在 shell 脚本上“赌公司的未来”？ [关闭]答案

【问题标题】：Why shouldn't I "bet the future of the company" on shell scripts? [closed]为什么我不应该在 shell 脚本上“赌公司的未来”？ [关闭]
【发布时间】：2010-09-06 05:51:26
【问题描述】：

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

何时不使用 shell 脚本

...

您押注于公司未来的关键任务应用程序

为什么不呢？

【问题讨论】：

标签： bash shell ksh

【解决方案1】：

无论我们都需要一个灵活的工具来与操作系统交互。这是与我们使用的操作系统的人类可读交互；这就像使用带有螺丝的螺丝刀。命令行将永远是我们需要管理员、程序员或网络的工具。看看他们甚至在 Powershell 上扩展的窗口。

【讨论】：

【解决方案2】：

当我读到这句话时，我关注的是“应用程序”部分，而不是“关键任务”部分。

我读到它是说 bash 不是用来编写应用程序的，它是用来编写脚本的。可以肯定的是，您的应用程序可能有一些管理脚本，但不要编写 critical-business-logic.sh，因为另一种语言可能更适合此类内容。

【讨论】：

【解决方案3】：

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

脚本带有 +r 的事实意味着用户可以制作脚本的副本，编辑/颠覆它，并执行他们编辑后的 Cuckoo's-Egg 版本。

【讨论】：

如果他们可以执行复制的shell脚本呢？如果用户可以创建一个文件并执行它，那么无论用户是复制文件还是从头开始编写都没有关系：无论哪种方式，执行的文件都具有相同的功能。

【解决方案4】：

当您利用它们的优势时，使用 shell 脚本很好。我公司有一些 5 类软交换机，呼叫处理代码和配置接口是用 java 编写的。其他一切都是用 KSH 编写的——用于备份、修剪、日志文件轮换和所有自动报告的数据库转储。我认为所有这些支持功能虽然与调用路径没有直接关系，但都是关键任务。尤其是数据库交互。如果 DB 交互代码出现问题并转储呼叫路由表，可能会使我们破产。

但没有什么会出错，因为 shell 脚本是处理这类事情的完美语言。它们很小，很容易理解，操纵文件是它们的强项，而且它们很稳定。这不像 KSH09 会被完全重写，因为有人认为它应该编译成字节码，所以它是一个稳定的接口。坦率地说，用 Java 编写的配置界面经常出现问题，而且我记得的 shell 脚本从来没有搞砸过。

【讨论】：

【解决方案5】：

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

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

【讨论】：

【解决方案6】：

脚本只不过是计算机程序。有些人会争辩说脚本不那么复杂。这些人通常会承认您可以用脚本语言编写复杂的代码，但这些脚本实际上不再是脚本，而是完全成熟的程序，根据定义。

随便。

在我看来，正确的答案是“视情况而定”。顺便说一句，这与您是否应该信任任务关键型应用程序的已编译可执行文件的相反问题的答案相同。

好的代码是好的，坏的代码是坏的——无论是写成 Bash 脚本、Windows CMD 文件、Python、Ruby、Perl、Basic、Forth、Ada、Pascal、Common Lisp、Cobol 还是编译C.

不是说语言的选择无关紧要。有时，选择特定语言或编译与解释有很好的理由（性能、可扩展性、能力、安全性等）。但是，在所有条件相同的情况下，我会相信一位出色的程序员编写的 shell 脚本，而不是一周中的任何一天由傻瓜编写的等效 C++ 程序。

【讨论】：

【解决方案7】：

显然，这对我来说有点像稻草人。我真的很想知道为什么人们认为应该在“关键任务应用程序”中避免使用 shell 脚本，但我想不出一个令人信服的理由。

例如，我见过（并编写过）一些使用 SQL*Plus 与 Oracle 数据库交互的 ksh 脚本。遗憾的是，系统无法正确扩展，因为查询没有使用绑定变量。打击 shell 脚本，对吧？错误的。问题不在于 shell 脚本，而在于 SQL*Plus。事实上，当我将 SQL*Plus 替换为连接到数据库并使用绑定变量的 Perl 脚本时，性能问题就消失了。

我可以很容易地想象将 shell 脚本放入航天器飞行软件中是个坏主意。但是 Java 或 C++ 可能是同样糟糕的选择。最好的选择是通常用于该目的的任何语言（汇编？）。

事实是，如果您使用任何风格的 Unix，那么假设您认为启动是关键任务，那么您就是在关键任务情况下使用 shell 脚本。当一个脚本需要做一些 shell 不擅长的事情时，你可以把这部分放到一个子程序中。你不会把剧本全部扔掉。

【讨论】：

【解决方案8】：

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

话虽如此，我认为您不想在 shell 脚本上构建任务关键型应用程序的原因是因为即使其他要点都不适用今天，任何要在一段时间内维护的应用程序都将演变到在某个时候至少被其中一个潜在的陷阱所困扰。 ....如果不彻底解决问题，您将无能为力。希望您从一开始就使用更具工业实力的东西。

【讨论】：

【解决方案9】：

我敢打赌，作者表明他们对 qualtiy wrt shell 脚本的某些方面感到不舒服。例如，谁对 BASH 脚本进行单元测试。

此外，脚本与底层操作系统的耦合度相当高，这可能是一件负面的事情。

【讨论】：

大多数语言在大多数方面都与操作系统相关。