Bash (Bash)、Z shell (zsh)、Fish (Fish)等shell语言和上面的脚本语言之间有什么区别,使它们更适合于shell?

在使用命令行时,shell语言似乎要容易得多。例如,对我来说,使用bash比在IPython中使用shell配置文件要流畅得多,尽管报告与此相反。我想大多数人都会同意我的观点,在Python中进行大部分中型到大型的编程比在Bash中更容易。我使用Python作为我最熟悉的语言。Perl和Ruby也是如此。

我试着阐明原因,但我不能,除了假设两者对字符串的不同处理与此有关。

提出这个问题的原因是我希望开发一种两者都可用的语言。如果你知道这样的语言,也请贴出来。

正如s .洛特所解释的,这个问题需要一些澄清。我问的是shell语言和脚本语言的特性。因此,比较不是关于各种交互(REPL)环境的特征,如历史记录和命令行替换。这个问题的另一种表达方式是:

适合于复杂系统设计的编程语言是否能够同时表达可以访问文件系统或控制作业的有用的一行程序?一种编程语言能有效地扩展和缩小吗?


当前回答

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

ls -laR /usr

not

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

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

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

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

其他回答

你在回避这个问题。并不是每个人都认为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.

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

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

它的文化。伯恩的外壳已经有将近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更好?”——但科技的进化,就像其他事物的进化一样,往往止步于足够好。“更好的”解决方案不会获胜,除非这种差异被视为一种破坏交易的挫败感。伯恩式脚本可能会让您感到沮丧,但对于一直使用它的人以及它所用于的工作来说,它总是能完成工作。

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

foo arg1 arg2 arg3

to

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

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

因此,您需要一个自定义shell(而不是REPL)来理解命令和重定向,以及您希望使用的将命令绑定在一起的语言。我认为zoid (Zoidberg 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程序员