它的文化。伯恩的外壳已经有将近25年的历史了;它是最早的脚本语言之一，也是Unix管理员核心需求的第一个很好的解决方案。(例如，将所有其他实用程序捆绑在一起的“胶水”，可以执行典型的Unix任务，而不必每次都编译一个该死的C程序。)

By modern standards, its syntax is atrocious and its weird rules and punctuation-as-statement style (useful in the 1970s when every byte counted) make it hard for non-admins to penetrate it. But it did the job. The flaws and shortcomings were addressed by evolutionary improvements in its descendants (ksh, bash, zsh) without having to reconceive the ideas behind it. Admins stuck to the core syntax because, weird as it was, nothing else handled the simple stuff better without getting in the way.

For complex stuff, Perl came along and morphed into a sort of half-admin, half-application language. But the more complex something gets, the more it's seen as an application rather than admin work, so the business people tend to look for "programmers" rather than "admins" to do it, despite the fact that the right kind of geek tends to be both. So that's where the focus went, and the evolutionary improvements to the application capabilities of Perl resulted in...well, Python and Ruby. (That's an oversimplification, but Perl was one of several inspirations for both languages.)

结果呢?专业化。管理员们倾向于认为现代解释性语言对于他们每天的工作来说太重量级了。总的来说，他们是对的。他们不需要对象。他们不关心数据结构。他们需要命令。他们需要胶水。没有什么比Bourne shell概念更好地尝试执行命令了(除了Tcl，这里已经提到过);伯恩已经足够好了。

Programmers -- who nowadays are having to learn about devops more and more -- look at the limitations of the Bourne shell and wonder how the hell anyone could put up with it. But the tools they know, while they certainly lean towards the Unixish style of I/O and file operations, aren't better for the purpose. I've written things like backup scripts and file renaming one-offs in Ruby, because I know it better than I know bash, but any dedicated admin could do the same thing in bash -- probably in fewer lines and with less overhead, but either way, it'd work just as well.

人们经常会问“为什么每个人都用Y，而Z更好?”——但科技的进化，就像其他事物的进化一样，往往止步于足够好。“更好的”解决方案不会获胜，除非这种差异被视为一种破坏交易的挫败感。伯恩式脚本可能会让您感到沮丧，但对于一直使用它的人以及它所用于的工作来说，它总是能完成工作。

由于这两种语言都是正式的编程语言，所以在一种语言中可以做的事情，在另一种语言中也可以做。实际上，这是一个设计重点问题。Shell语言是为交互使用而设计的，而脚本语言不是。

The basic difference in the design is the storage of data between commands and the scope of variables. In Bash, etc. you have to jump through hoops to store a value (for example, commands like set a='something'), while in languages like Python you simply use an assignment statement (a = 'something'). When using the values in a shell language you have to tell the language that your want the value of the variable, while in scripting languages you have to tell the language when you want the immediate value of the string. This has effects when used interactively.

在脚本语言中，ls被定义为命令

a = some_value

ls a*b  

(a是什么意思?这意味着some_value *(不管b是什么)还是你的意思 “'anystring b ?。在脚本语言中，默认值是存储在内存中的。)

ls 'a*b'  Now means what the Unix ls a*b means.

用类似bash的语言

set a=some_value

ls a*b   means what the Unix ls a*b means.

ls $a*b  uses an explicit recall of the value of a.

脚本语言使得存储和检索值变得容易，而值上的瞬态作用域却很难实现。Shell语言可以存储和调用值，但是每个命令的作用域都是短暂的。

它的文化。伯恩的外壳已经有将近25年的历史了;它是最早的脚本语言之一，也是Unix管理员核心需求的第一个很好的解决方案。(例如，将所有其他实用程序捆绑在一起的“胶水”，可以执行典型的Unix任务，而不必每次都编译一个该死的C程序。)

By modern standards, its syntax is atrocious and its weird rules and punctuation-as-statement style (useful in the 1970s when every byte counted) make it hard for non-admins to penetrate it. But it did the job. The flaws and shortcomings were addressed by evolutionary improvements in its descendants (ksh, bash, zsh) without having to reconceive the ideas behind it. Admins stuck to the core syntax because, weird as it was, nothing else handled the simple stuff better without getting in the way.

For complex stuff, Perl came along and morphed into a sort of half-admin, half-application language. But the more complex something gets, the more it's seen as an application rather than admin work, so the business people tend to look for "programmers" rather than "admins" to do it, despite the fact that the right kind of geek tends to be both. So that's where the focus went, and the evolutionary improvements to the application capabilities of Perl resulted in...well, Python and Ruby. (That's an oversimplification, but Perl was one of several inspirations for both languages.)

结果呢?专业化。管理员们倾向于认为现代解释性语言对于他们每天的工作来说太重量级了。总的来说，他们是对的。他们不需要对象。他们不关心数据结构。他们需要命令。他们需要胶水。没有什么比Bourne shell概念更好地尝试执行命令了(除了Tcl，这里已经提到过);伯恩已经足够好了。

Programmers -- who nowadays are having to learn about devops more and more -- look at the limitations of the Bourne shell and wonder how the hell anyone could put up with it. But the tools they know, while they certainly lean towards the Unixish style of I/O and file operations, aren't better for the purpose. I've written things like backup scripts and file renaming one-offs in Ruby, because I know it better than I know bash, but any dedicated admin could do the same thing in bash -- probably in fewer lines and with less overhead, but either way, it'd work just as well.

人们经常会问“为什么每个人都用Y，而Z更好?”——但科技的进化，就像其他事物的进化一样，往往止步于足够好。“更好的”解决方案不会获胜，除非这种差异被视为一种破坏交易的挫败感。伯恩式脚本可能会让您感到沮丧，但对于一直使用它的人以及它所用于的工作来说，它总是能完成工作。

No.

不，脚本语言可能不适合shell。

问题在于宏语言和其他所有语言之间的二分法。

shell与其他遗留宏语言(如nroff和m4)属于一类。在这些处理器中，所有内容都是字符串，处理器定义了从输入字符串到输出字符串的映射。

在所有语言中，某些边界都是双向交叉的，但通常很清楚系统的类别是宏观的还是，嗯，我不知道有一个官方术语……我会说“一种真正的语言”。

当然，您可以用Ruby这样的语言输入所有的命令，它甚至可能是仅次于真正shell的次优选择，但它永远不会是宏语言。有太多的语法需要考虑。它需要太多的引号。

但是在开始使用宏语言编程时，宏语言也有它自己的问题，因为必须做出太多妥协才能摆脱所有语法。输入字符串时不带引号。需要重新引入各种神奇的方法来注入缺失的语法。我在nroff做过一次code-golf，就是为了与众不同。这很奇怪。宏语言中大型实现的源代码是可怕的。

谁说他们不是?看看Zoidberg。REPLs (Read Eval Print Loops)会产生糟糕的shell，因为每个命令都必须在语法上正确，运行一个程序会从:

foo arg1 arg2 arg3

to

system "foo", "arg1", "arg2", "arg3"

更不要让我开始尝试重定向。

因此，您需要一个自定义shell(而不是REPL)来理解命令和重定向，以及您希望使用的将命令绑定在一起的语言。我认为zoid (Zoidberg shell)在这方面做得很好。

这些答案激励我接管基于perl的shell Zoidberg的维护工作。经过一些修复后，它又可以使用了!

查看用户指南或使用您最喜欢的CPAN客户端安装Bundle::Zoidberg。