我认为这是一个分析的问题。Shell语言默认假设普通的$ xxx命令意味着要运行的命令。在Python和Ruby中需要你做系统(“命令”)或其他什么。

并不是说它们不合适，只是还没有人真正做过;至少我是这么认为的。Rush是Ruby中的一个例子，Python有IPython或类似的东西。

shell语言必须易于使用。您希望键入一次性的丢弃命令，而不是小程序。也就是说，你想要打字

ls -laR /usr

not

shell.ls("/usr", long=True, all=True, recursive=True)

这(也)意味着shell语言并不真正关心参数是选项、字符串、数字还是其他东西。

此外，shell中的编程构造是一个附加组件，甚至不总是内置的。例如，考虑Bash或Bourne shell (sh)中if和[的组合，用于生成序列的seq，等等。

最后，shell具有在编程中较少或不同的特定需求。例如，管道、文件重定向、进程/作业控制等等。

如果你知道这样的语言，也请贴出来。

Tcl就是这样一种语言。主要是因为它主要被设计为CAD程序的shell解释器。以下是一位铁杆Python程序员体会到Tcl为何被设计成这样的经历:我不敢相信我在称赞Tcl

对我来说，我已经编写并一直在使用并改进了Tcl shell(当然是用Tcl编写的)，作为我在自制路由器上的主要Linux登录shell: Pure Tcl readline

总的来说，我喜欢Tcl的一些原因与它与传统shell的语法相似有关:

At its most basic, Tcl syntax is command argument argument.... There's nothing else. This is the same as Bash, C shell or even DOS shell. A bareword is considered a string. This is again similar to traditional shells allowing you to write: open myfile.txt w+ instead of open "myfile.txt" "w+". Because of the foundations of 1 and 2, Tcl ends up with very little extraneous syntax. You write code with less punctuation: puts Hello instead of printf("Hello");. When writing programs you don't feel the hurt so much, because you spend a lot of time thinking about what to write. When you use a shell to copy a file you don't think you just type and having to type ( and " and , and ) and ; again and again gets annoying very quickly.

*注:不是我;我是一个铁杆的Tcl程序员

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

foo arg1 arg2 arg3

to

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

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

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

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

Python & Co. are designed to be good at scripting. Bash & Co. are designed to be only good at scripting, with absolutely no compromise. IOW: Python is designed to be good both at scripting and non-scripting, Bash cares only about scripting. Bash & Co. are untyped, Python & Co. are strongly typed, which means that the number 123, the string 123 and the file 123 are quite different. They are, however, not statically typed, which means they need to have different literals for those, in order to keep them apart. Example: | 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. are designed to scale up to 10000, 100000, maybe even 1000000 line programs, Bash & Co. are designed to scale down to 10 character programs. In Bash & Co., files, directories, file descriptors, processes are all first-class objects, in Python, only Python objects are first-class, if you want to manipulate files, directories etc., you have to wrap them in a Python object first. Shell programming is basically dataflow programming. Nobody realizes that, not even the people who write shells, but it turns out that shells are quite good at that, and general-purpose languages not so much. In the general-purpose programming world, dataflow seems to be mostly viewed as a concurrency model, not so much as a programming paradigm.

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

实际上，恕我直言，目前最好的外壳是微软的PowerShell，这是非常令人惊讶的，因为几十年来，微软一直有最糟糕的外壳。我是说，COMMAND.COM?真的吗?(不幸的是，他们的终端仍然很糟糕。它仍然是“命令提示符”，从那时起，什么?Windows 3.0 ?)

PowerShell基本上是通过忽略微软曾经做过的所有事情(COMMAND.COM, CMD.EXE, VBScript, JScript)来创建的，而是从Unix shell开始，然后删除所有向后兼容的问题(比如命令替换的反勾号)，并对它进行了一些调整，使其更适合Windows(比如使用现在不使用的反勾号作为转义字符，而不是Windows中的路径组件分隔符反斜杠字符)。之后，就是奇迹发生的时候了。

They address problem 1 and 3 from above, by basically making the opposite choice compared to Python. Python cares about large programs first, scripting second. Bash cares only about scripting. PowerShell cares about scripting first, large programs second. A defining moment for me was watching a video of an interview with Jeffrey Snover (PowerShell's lead designer), when the interviewer asked him how big of a program one could write with PowerShell and Snover answered without missing a beat: "80 characters." At that moment I realized that this is finally a guy at Microsoft who "gets" shell programming (probably related to the fact that PowerShell was neither developed by Microsoft's programming language group (i.e. lambda-calculus math nerds) nor the OS group (kernel nerds) but rather the server group (i.e. sysadmins who actually use shells)), and that I should probably take a serious look at PowerShell.

Number 2 is solved by having arguments be statically typed. So, you can write just 123 and PowerShell knows whether it is a string or a number or a file, because the cmdlet (which is what shell commands are called in PowerShell) declares the types of its arguments to the shell. This has pretty deep ramifications: unlike Unix, where each command is responsible for parsing its own arguments (the shell basically passes the arguments as an array of strings), argument parsing in PowerShell is done by the shell. The cmdlets specify all their options and flags and arguments, as well as their types and names and documentation(!) to the shell, which then can perform argument parsing, tab completion, IntelliSense, inline documentation popups etc. in one centralized place. (This is not revolutionary, and the PowerShell designers acknowledge shells like the DIGITAL Command Language (DCL) and the IBM OS/400 Command Language (CL) as prior art. For anyone who has ever used an AS/400, this should sound familiar. In OS/400, you can write a shell command and if you don't know the syntax of certain arguments, you can simply leave them out and hit F4, which will bring a menu (similar to an HTML form) with labelled fields, dropdown, help texts etc. This is only possible because the OS knows about all the possible arguments and their types.) In the Unix shell, this information is often duplicated three times: in the argument parsing code in the command itself, in the bash-completion script for tab-completion and in the manpage.

第4个问题可以通过PowerShell对强类型对象(包括文件、进程、文件夹等)进行操作来解决。

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

Another nice thing about PowerShell are the naming conventions: all cmdlets are named Action-Object and moreover, there are also standardized names for specific actions and specific objects. (Again, this should sound familar to OS/400 users.) For example, everything which is related to receiving some information is called Get-Foo. And everything operating on (sub-)objects is called Bar-ChildItem. So, the equivalent to ls is Get-ChildItem (although PowerShell also provides builtin aliases ls and dir – in fact, whenever it makes sense, they provide both Unix and CMD.EXE aliases as well as abbreviations (gci in this case)).

But the killer feature IMO is the strongly typed object pipelines. While PowerShell is derived from the Unix shell, there is one very important distinction: in Unix, all communication (both via pipes and redirections as well as via command arguments) is done with untyped, unstructured strings. In PowerShell, it's all strongly typed, structured objects. This is so incredibly powerful that I seriously wonder why noone else has thought of it. (Well, they have, but they never became popular.) In my shell scripts, I estimate that up to one third of the commands is only there to act as an adapter between two other commands that don't agree on a common textual format. Many of those adapters go away in PowerShell, because the cmdlets exchange structured objects instead of unstructured text. And if you look inside the commands, then they pretty much consist of three stages: parse the textual input into an internal object representation, manipulate the objects, convert them back into text. Again, the first and third stage basically go away, because the data already comes in as objects.

然而，设计人员通过所谓的自适应类型系统(Adaptive Type System)非常小心地保持了shell脚本的动态性和灵活性。

Anyway, I don't want to turn this into a PowerShell commercial. There are plenty of things that are not so great about PowerShell, although most of those have to do either with Windows or with the specific implementation, and not so much with the concepts. (E.g. the fact that it is implemented in .NET means that the very first time you start up the shell can take up to several seconds if the .NET framework is not already in the filesystem cache due to some other application that needs it. Considering that you often use the shell for well under a second, that is completely unacceptable.)

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

由于这两种语言都是正式的编程语言，所以在一种语言中可以做的事情，在另一种语言中也可以做。实际上，这是一个设计重点问题。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语言可以存储和调用值，但是每个命令的作用域都是短暂的。

可伸缩性和可扩展性?通用Lisp(甚至可以在Unix环境中作为登录shell运行clip和其他实现)。

它的文化。伯恩的外壳已经有将近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，就是为了与众不同。这很奇怪。宏语言中大型实现的源代码是可怕的。

对于Windows用户，我还没有感觉到对PowerShell的需求，因为我仍然使用JP Software的4NT(现在是Take Command Console)。它是一个非常好的shell，具有很多编程功能。所以它结合了两个世界的优点。

例如，当您研究IRB (Ruby解释器)时，一定很有可能使用更多的一行程序来扩展它，以执行日常脚本化或大规模文件管理，以及处理分钟级任务。

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

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

你在回避这个问题。并不是每个人都认为shell语言更好。首先，_为什么不呢

Not long ago a friend asked me how to recursively search his PHP scripts for a string. He had a lot of big binary files and templates in those directories that could have really bogged down a plain grep. I couldn't think of a way to use grep to make this happen, so I figured using find and grep together would be my best bet. find . -name "*.php" -exec grep 'search_string' {} \; -print Here's the above file search reworked in Ruby: Dir['**/*.php'].each do |path| File.open( path ) do |f| f.grep( /search_string/ ) do |line| puts path, ':', line end end end Your first reaction may be, "Well, that's quite a bit wordier than the original." And I just have to shrug and let it be. "It's a lot easier to extend," I say. And it works across platforms.