为什么我不应该在shell脚本上“打赌公司的未来”?

时间:2008-08-19 23:50:47

标签: bash shell ksh

我看着http://tldp.org/LDP/abs/html/why-shell.html并被以下人员震惊:

  

何时不使用shell脚本

     

...

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

为什么不呢?

9 个答案:

答案 0 :(得分:13)

使用shell脚本在使用自己的优势时很好。我的公司有一些5类软交换机,呼叫处理代码和配置接口是用java编写的。其他所有内容都是用KSH编写的 - 用于备份,修剪,日志文件轮换和所有自动报告的数据库转储。我认为所有这些支持功能虽然与呼叫路径没有直接关系,但却是关键任务。特别是数据库交互。如果数据库交互代码出现问题并转储了呼叫路由表,则可能导致我们无法使用。

但是没有任何问题,因为shell脚本是这类东西的完美语言。它们很小,很容易理解,操纵文件是它们的强项,而且它们很稳定。它不像KSH09将是一个完全重写,因为有人认为它应该编译为字节代码,所以它是一个稳定的接口。坦率地说,用Java编写的配置界面经常变得非常糟糕,shell脚本从未搞砸过,我记得很清楚。

答案 1 :(得分:6)

我觉得这篇文章指出了一个非常好的清单,列出了不使用shell脚本的原因 - 你指出的单一任务关键子弹更多的是基于所有其他子弹的结论。

话虽如此,我认为您不希望在shell脚本上构建关键任务应用程序的原因是因为即使其他子弹点都没有应用 今天 ,任何将在一段时间内保持的应用程序将 演变 到某一点上至少有一个潜在的陷阱。 ....如果没有一个完整的做法来提出解决方案,那么你真的无法做任何事情......希望你从一开始就使用更具工业实力的东西。 / p>

答案 2 :(得分:5)

脚本不过是计算机程序。有些人认为脚本不太复杂。这些人通常会承认你可以用脚本语言编写复杂的代码,但是根据定义,这些脚本不再是脚本,而是完整的程序。

无论。

在我看来,正确答案是“它取决于”。顺便说一下,对于你是否应该信任任务关键型应用程序的已编译可执行文件这个相反的问题,这是一个答案。

良好的代码是好的,糟糕的代码是坏的 - 无论是作为Bash脚本,Windows CMD文件,Python,Ruby,Perl,Basic,Forth,Ada,Pascal,Common Lisp,Cobol还是编译下进行。

表示选择语言并不重要。有时,选择特定语言或编译与解释有很好的理由(性能,可扩展性,功能,安全性等)。但是,在所有条件相同的情况下,我会相信一个伟大的程序员编写的shell脚本,而不是一周中任何一天由doofus编写的等效C ++程序。

答案 3 :(得分:5)

显然,这对我来说是一个吸血鬼。我真的很感兴趣为什么人们认为在“任务关键型应用程序”中应该避免使用shell脚本,但我想不出一个令人信服的理由。

例如,我已经看过(并编写过)一些使用SQL * Plus与Oracle数据库交互的ksh脚本。遗憾的是,系统无法正确扩展,因为查询不使用绑定变量。针对shell脚本进行攻击,对吧?错误。问题不在于shell脚本,而在于SQL * Plus。事实上,当我用一个连接到数据库并使用绑定变量的Perl脚本替换SQL * Plus时,性能问题就消失了。

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

事实是,如果你使用任何类型的Unix,你就会在任务关键的情况下使用shell脚本,假设你认为启动是关键任务。当脚本需要执行shell不是特别擅长的操作时,您将该部分放入子程序中。你不要扔掉批发的脚本。

答案 4 :(得分:2)

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

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

答案 5 :(得分:2)

当我读到这篇文章时,我会关注“应用程序”部分,而不是“关键任务”部分。

我读到它是因为bash不是用于编写应用程序,而是脚本编写。当然,您的应用程序可能有一些内务处理脚本但不写critical-business-logic.sh,因为另一种语言可能更适合这样的东西。

答案 6 :(得分:0)

我敢打赌作者表示他们对shell脚本编写质量的某些方面感到不舒服。例如,谁对BASH脚本进行单元测试。

脚本也与底层操作系统紧密耦合,这可能是一种负面的东西。

答案 7 :(得分:0)

无论我们都是一个与os交互的灵活工具。它是我们使用的与人类可读的交互,就像使用带螺丝的螺丝刀一样。命令行永远是我们需要管理员,程序员或网络的atool。看看窗口,他们甚至扩展了他们的powershell。

答案 8 :(得分:-2)

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

脚本具有+ r意味着用户可以制作脚本的副本,编辑/破坏它,并执行他们编辑的Cuckoo's-Egg版本。

相关问题