python - 为什么脚本语言(例如 Perl、Python、Ruby)不适合作为 shell 语言？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。




8年前关闭。




像bash这样的shell语言有什么区别？ , zsh , fish上面的脚本语言使它们更适合shell？

使用命令行时，shell 语言似乎要容易得多。例如，我觉得使用 bash 比使用 ipython 中的 shell 配置文件要流畅得多，despite reports to the contrary .我认为大多数人都会同意我的观点，Python 中的大部分中型到大型编程比 bash 更容易。我使用 Python 作为我最熟悉的语言，Perl 和 Ruby 也是如此。

我试图阐明原因，但除了假设两者中对字符串的不同处理与此有关之外，我无法阐明原因。

这个问题的原因是我希望开发一种在两者中都可用的语言。如果你知道这种语言，也请张贴。

正如 S.Lott 所解释的，这个问题需要澄清一下。我在询问 shell 语言的特性与脚本语言的特性。所以比较不是关于历史和命令行替换等各种交互式( REPL )环境的特性。该问题的另一种表达方式是:

一种适用于复杂系统设计的编程语言能否同时表达有用的单行代码，可以访问文件系统或控制作业？编程语言可以有效地扩展和缩减吗？

Answer 1

我能想到一些不同之处；只是思想流在这里，没有特别的顺序:

Python & Co. 旨在擅长编写脚本。 Bash & Co. 旨在只擅长编写脚本，绝对不妥协。 IOW:Python 被设计成擅长脚本和非脚本，Bash 只关心脚本。

Bash & Co. 是无类型的，Python & Co. 是强类型的，这意味着数字 123 , 字符串 123和文件 123是完全不同的。然而，它们不是静态类型的，这意味着它们需要有不同的文字，以便将它们分开。
例子:

                | Ruby             | Bash    
-----------------------------------------
number          | 123              | 123
string          | '123'            | 123
regexp          | /123/            | 123
file            | File.open('123') | 123
file descriptor | IO.open('123')   | 123
URI             | URI.parse('123') | 123
command         | `123`            | 123

Python & Co. 旨在扩展到 10000、100000，甚至 1000000 行程序，Bash & Co. 旨在缩减到 10 个字符程序。

在 Bash & Co. 中，文件、目录、文件描述符、进程都是一等对象，在 Python 中，只有 Python 对象是一等对象，如果要操作文件、目录等，必须将它们包装在一个首先是 Python 对象。

Shell编程基本上是数据流编程。没有人意识到这一点，即使是编写 shell 的人也没有意识到，但事实证明，shell 非常擅长这一点，而通用语言则不然。在通用编程世界中，数据流似乎主要被视为一种并发模型，而不是一种编程范式。

我有一种感觉，试图通过将特性或 DSL 固定到通用编程语言上来解决这些问题是行不通的。至少，我还没有看到令人信服的实现。有 RuSH (Ruby shell)，它试图在 Ruby 中实现一个 shell，有 rush ，它是 Ruby 中 shell 编程的内部 DSL，有 Hotwire ，这是一个 Python shell，但 IMO 没有一个能与 Bash、Zsh、fish 和 friend 竞争。

实际上，恕我直言，目前最好的 shell 是 Microsoft PowerShell ，考虑到几十年来，微软一直拥有最糟糕的 shell evar，这是非常令人惊讶的。我的意思是， COMMAND.COM ?真的吗？ (不幸的是，他们仍然有一个蹩脚的终端。它仍然是从那以后一直存在的“命令提示符”，什么？Windows 3.0？)

PowerShell 基本上是通过忽略 Microsoft 做过的所有事情( COMMAND.COM 、 CMD.EXE 、VBScript、JScript)而创建的，而是从 Unix shell 开始，然后删除所有向后兼容的 cruft(如用于命令替换的反引号)并对其进行按摩位使其更适合 Windows(例如使用现在未使用的反引号作为转义字符而不是反斜杠，反斜杠是 Windows 中的路径组件分隔符)。在那之后，就是魔法发生的时候。

他们的地址是 问题 1 和 3 从上面开始，与 Python 相比，基本上做出了相反的选择。 Python首先关心大型程序，其次编写脚本。 Bash 只关心脚本。 PowerShell 首先关心脚本编写，其次才是大程序。对我来说，一个决定性的时刻是观看 Jeffrey Snover(PowerShell 的首席设计师)的采访视频，当面试官问他可以用 PowerShell 编写多大的程序时，Snover 毫不犹豫地回答:“80 个字符。”那一刻我意识到，这终于是微软的一个“获得”shell编程的人了(可能与PowerShell既不是由微软的编程语言组(即lambda-calculus math nerds)也不是由操作系统组(kernel nerds)开发的事实有关) 而是服务器组(即实际使用 shell 的系统管理员))，我可能应该认真研究一下 PowerShell。

2号是通过静态输入参数来解决的。所以，你可以只写 123 PowerShell 知道它是字符串、数字还是文件，因为 cmdlet(这是在 PowerShell 中调用的 shell 命令)向 shell 声明其参数的类型。这有很深的影响:与 Unix 不同，在 Unix 中，每个命令负责解析自己的参数(shell 基本上将参数作为字符串数组传递)，PowerShell 中的参数解析由 shell 完成。 cmdlet 将所有选项、标志和参数，以及它们的类型、名称和文档(!)指定给 shell，然后 shell 可以在一个集中的地方执行参数解析、制表符完成、智能感知、内联文档弹出等。 (这不是革命性的，PowerShell 设计者承认像 DIGITAL 命令语言 (DCL) 和 IBM OS/400 命令语言 (CL) 这样的 shell 是现有技术。对于曾经使用过 AS/400 的任何人来说，这听起来应该很熟悉. 在 OS/400 中，您可以编写一个 shell 命令，如果您不知道某些参数的语法，您可以简单地将它们省略并按 F4，这将显示一个带有标记字段的菜单(类似于 HTML 表单) 、下拉菜单、帮助文本等。这是唯一可能的，因为操作系统知道所有可能的参数及其类型。)在 Unix shell 中，此信息通常重复三遍:在命令本身的参数解析代码中，在 bash-completion用于选项卡完成和联机帮助页中的脚本。

4号 PowerShell 对强类型对象(包括文件、进程、文件夹等内容)进行操作这一事实解决了这个问题。

5号特别有趣，因为 PowerShell 是我所知道的唯一一个 shell，编写它的人实际上意识到 shell 本质上是数据流引擎，并故意将其实现为数据流引擎。

PowerShell 的另一个好处是命名约定:所有 cmdlet 都命名为 Action-Object而且，对于特定的 Action 和特定的对象，也有标准化的名称。 (同样，这对于 OS/400 用户来说应该很熟悉。)例如，与接收某些信息相关的所有内容都称为 Get-Foo。 .对(子)对象进行操作的所有内容都称为 Bar-ChildItem .所以，相当于 ls是 Get-ChildItem (尽管 PowerShell 还提供了内置别名 ls 和 dir – 事实上，只要有意义，它们就会同时提供 Unix 和 CMD.EXE 别名以及缩写(在本例中为 gci))。

但是 杀手级功能 IMO 是强类型对象管道。虽然 PowerShell 源自 Unix shell，但有一个非常重要的区别:在 Unix 中，所有通信(通过管道和重定向以及通过命令参数)都是使用无类型、无结构的字符串完成的。在 PowerShell 中，它都是强类型的结构化对象。这是如此令人难以置信的强大，以至于我真的很想知道为什么没有其他人想到它。 (嗯，他们有，但他们从来没有流行过。)在我的 shell 脚本中，我估计多达三分之一的命令只是在那里充当其他两个不同意通用文本格式的命令之间的适配器.许多适配器在 PowerShell 中消失了，因为 cmdlet 交换结构化对象而不是非结构化文本。如果您查看命令的内部，那么它们几乎由三个阶段组成:将文本输入解析为内部对象表示、操作对象、将它们转换回文本。同样，第一和第三阶段基本上消失了，因为数据已经作为对象进来了。

然而，设计者通过他们所谓的自适应类型系统非常小心地保留了 shell 脚本的动态性和灵活性。

无论如何，我不想把它变成一个 PowerShell 商业广告。 PowerShell 有很多不太好的地方，尽管其中大部分都与 Windows 或特定实现有关，而与概念无关。 (例如，它是在 .NET 中实现的，这意味着如果 .NET 框架由于某些其他应用程序需要它而尚未在文件系统缓存中，那么第一次启动 shell 可能需要几秒钟的时间。考虑您经常使用 shell 不到一秒钟，这是完全 Not Acceptable 。)

我想说的最重要的一点是，如果您想查看脚本语言和 shell 方面的现有工作， 你不应该停留在 Unix 和 Ruby/Python/Perl/PHP 家族 .例如， Tcl已经提到了。 Rexx将是另一种脚本语言。 Emacs Lisp将是另一个。在 shell 领域，有一些已经提到的大型机/中端 shell ，例如 OS/400 命令行和 DCL。此外，Plan9 的 rc。