我正在查看http://tldp.org/LDP/abs/html/why-shell.html并被以下内容震惊：
何时不使用 shell 脚本
...
- 您押注于公司未来的关键任务应用程序
为什么不？
Jon Ericson
问问题
4003 次
9 回答
16
当您使用它们的优势时，使用 shell 脚本很好。我公司有一些 5 类软交换机，呼叫处理代码和配置接口是用 java 编写的。其他一切都是用 KSH 编写的 - 用于备份、修剪、日志文件轮换和所有自动报告的数据库转储。我认为所有这些支持功能，虽然与调用路径没有直接关系，但都是关键任务。尤其是数据库交互。如果 DB 交互代码出现问题并转储呼叫路由表，它可能会让我们破产。
但是没有什么会出错，因为 shell 脚本是处理这类事情的完美语言。它们很小，很容易理解，操纵文件是它们的强项，而且它们很稳定。这不像 KSH09 会被完全重写，因为有人认为它应该编译成字节码，所以它是一个稳定的接口。坦率地说，用 Java 编写的配置接口经常出现问题，而且我记得的 shell 脚本从来没有搞砸过。
于 2008-08-20T03:12:01.313 回答
6
我有点认为这篇文章指出了一个非常好的不使用 shell 脚本的原因列表——你指出的单个关键任务项目符号更多的是基于所有其他项目符号的结论。
话虽如此，我认为您不想在 shell 脚本上构建任务关键型应用程序的原因是，即使今天没有其他要点适用，任何要在一段时间内维护的应用程序都会发展到了在某个时候至少被其中一个潜在的陷阱咬住的地步……如果没有彻底解决，你将无能为力有一个修复....希望你从一开始就使用更具工业实力的东西。
于 2008-08-20T00:17:20.890 回答
6
脚本只不过是计算机程序。有些人会争辩说脚本不那么复杂。这些人通常会承认您可以用脚本语言编写复杂的代码，但这些脚本实际上不再是脚本，而是根据定义的成熟程序。
任何。
在我看来，正确的答案是“视情况而定”。顺便说一句，这与您是否应该信任任务关键型应用程序的已编译可执行文件的相反问题的答案相同。
好的代码是好的，坏的代码是坏的——无论是写成 Bash 脚本、Windows CMD 文件、Python、Ruby、Perl、Basic、Forth、Ada、Pascal、Common Lisp、Cobol 还是编译的 C。
这并不是说语言的选择无关紧要。 有时，选择特定语言或编译与解释（性能、可扩展性、能力、安全性等）有很好的理由。但是，在所有条件相同的情况下，我会相信一个伟大的程序员编写的 shell 脚本，而不是一周中的任何一天由傻瓜编写的等效 C++ 程序。
于 2008-08-20T00:29:22.360 回答
5
显然，这对我来说有点像稻草人。我真的很感兴趣为什么人们认为应该在“关键任务应用程序”中避免使用 shell 脚本，但我想不出一个令人信服的理由。
例如，我见过（并编写过）一些使用 SQL*Plus 与 Oracle 数据库交互的 ksh 脚本。遗憾的是，系统无法正确扩展，因为查询没有使用绑定变量。打击 shell 脚本，对吧？错误的。问题不在于 shell 脚本，而在于 SQL*Plus。事实上，当我用连接到数据库并使用绑定变量的 Perl 脚本替换 SQL*Plus 时，性能问题就消失了。
我可以很容易地想象将 shell 脚本放在航天器飞行软件中是个坏主意。但是 Java 或 C++ 可能是同样糟糕的选择。最好的选择是通常用于该目的的任何语言（汇编？）。
事实是，如果您使用任何风格的 Unix，假设您认为启动是关键任务，那么您就是在关键任务情况下使用 shell 脚本。当一个脚本需要做一些 shell 不擅长的事情时，你可以把这部分放到一个子程序中。你不会把剧本批发扔掉。
于 2008-08-20T00:33:25.547 回答
2
帮助公司走向未来的可能是 shell 脚本。我只是从编程的角度知道，我会浪费大量时间来执行我委托给 shell 脚本的重复性任务。例如，我知道命令行的大多数颠覆命令，但如果我可以将所有这些命令集中到一个脚本中，我可以随意触发，我可以节省时间和精力。
就像其他一些人所说的那样，语言是一个因素。对于我简短的不想记住的步骤和粘合程序，我完全信任我的 shell 脚本并依赖它们。这并不意味着我要构建一个在后端运行 bash 的网站，但我肯定会使用 bash/ksh/python/whatever 来帮助我生成框架项目并管理我的打包和部署。
于 2008-08-20T02:46:48.737 回答
2
当我阅读这句话时，我关注的是“应用程序”部分而不是“关键任务”部分。
我读到它是说 bash 不是用来编写应用程序的，它是用来编写脚本的。所以可以肯定的是，您的应用程序可能有一些管理脚本，但不要编写critical-business-logic.sh，因为另一种语言可能更适合这样的东西。
于 2008-09-18T13:00:17.133 回答
0
我敢打赌作者表明他们对 qualtiy wrt shell 脚本的某些方面感到不舒服。例如，谁对 BASH 脚本进行单元测试。
此外，脚本与底层操作系统的耦合度相当高，这可能是一件负面的事情。
于 2008-08-19T23:58:32.543 回答
0
不管我们都需要一个灵活的工具来与 os 交互。这是与我们使用的操作系统的人类可读交互；这就像使用带有螺丝的螺丝刀。命令行将永远是我们需要管理员、程序员或网络的工具。看看他们甚至在 Powershell 上扩展的窗口。
于 2015-05-17T05:37:47.910 回答
-2
脚本不适合实现某些关键任务功能，因为它们必须同时具有 +r 和 +x 权限才能运行。可执行文件只需要 +x。
脚本具有 +r 的事实意味着用户可以制作脚本的副本，编辑/颠覆它，并执行他们编辑的 Cuckoo's-Egg 版本。
于 2008-09-18T11:54:25.623 回答