我正在查看http://tldp.org/LDP/abs/html/why-shell.html并对此感到震惊:
何时不使用shell脚本
...
任务关键型应用程序,您在该应用程序上押注公司的未来
为什么不？
当你使用它们的优势时,使用shell脚本是很好的.我的公司有一些5类软交换机,呼叫处理代码和配置接口是用java编写的.其他所有内容都是用KSH编写的 - 用于备份,修剪,日志文件轮换和所有自动报告的数据库转储.我认为所有这些支持功能虽然与呼叫路径没有直接关系,但却是关键任务.特别是数据库交互.如果数据库交互代码出现问题并转储了呼叫路由表,则可能导致我们破产.
但是没有任何问题出错,因为shell脚本是这类东西的完美语言.它们很小,很容易理解,操纵文件是它们的强项,而且它们很稳定.它不像KSH09将是一个完全重写,因为有人认为它应该编译为字节代码,所以它是一个稳定的接口.坦率地说,用Java编写的配置界面经常变得非常糟糕,并且shell脚本从未搞砸过我记忆中的问题.
我认为这篇文章指出了一个非常好的清单,列出了不使用shell脚本的原因 - 你指出的单一任务关键子弹更多的是基于所有其他子弹的结论.
话虽如此,我认为您不希望在shell脚本上构建关键任务应用程序的原因是因为即使今天没有其他要点适用,任何将在一段时间内维护的应用程序也会发生变化至少在某些方面至少有一个潜在的陷阱......并且没有任何东西你真的能够做到这一点而不是一个完整的事情来做修复....希望你从一开始就使用更具工业实力的东西.
脚本没有比计算机程序更多或更少.有些人认为脚本不太复杂.这些人通常会承认你可以用脚本语言编写复杂的代码,但是根据定义,这些脚本不再是脚本,而是完整的程序.
随你.
在我看来,正确的答案是"它取决于".顺便说一下,对于您是否应该信任任务关键型应用程序的已编译可执行文件这一相反问题,这是一个相同的答案.
良好的代码是好的,糟糕的代码是坏的 - 无论是作为Bash脚本,Windows CMD文件,Python,Ruby,Perl,Basic,Forth,Ada,Pascal,Common Lisp,Cobol还是编译C编写.
这并不是说语言的选择无关紧要. 有时,选择特定语言或编译与解释(性能,可伸缩性,功能,安全性等)有很好的理由.但是,在所有条件相同的情况下,我会相信一个伟大的程序员编写的shell脚本,而不是一周中任何一天由doofus编写的等效C++程序.
显然,这对我来说是一个吸引人的人.我真的很感兴趣为什么人们认为在"任务关键型应用程序"中应该避免使用shell脚本,但我想不出一个令人信服的理由.
例如,我已经看过(并编写过)一些使用SQL*Plus与Oracle数据库交互的ksh脚本.遗憾的是,系统无法正确扩展,因为查询不使用绑定变量.针对shell脚本进行攻击,对吧？错误.问题不在于shell脚本,而在于SQL*Plus.事实上,当我用一个连接到数据库并使用绑定变量的Perl脚本替换SQL*Plus时,性能问题就消失了.
我很容易想象将shell脚本放入航天器飞行软件中是一个坏主意.但Java或C++可能是同样糟糕的选择.最好的选择是通常用于此目的的任何语言(汇编？).
事实上,如果你使用任何类型的Unix,你就会在任务关键的情况下使用shell脚本,假设你认为启动是关键任务.当脚本需要执行shell不是特别擅长的操作时,您将该部分放入子程序中.你不要扔掉脚本批发.
京公网安备 11010802040832号 | 京ICP备19059560号-6 