主流* NIX外壳之间的根本区别是什么?[关闭]


52

主流* NIX shell之间的根本区别是什么?哪些情况可能会提示您使用另一种?我知道其中的一些可能取决于用户的偏好,但是我只使用过bash,所以我很想听听其他shell可能有用的地方。

另外,在一个或多个Shell下运行时,是否会对用户编写的Shell脚本产生影响,还是仅仅是在文件顶部更改Shell?我的直觉说这并不容易。

Answers:


52

对于交互使用,有两个主要竞争者,bashzsh,以及散乱的tcsh和newcomer fish

  • Bash是GNU项目的官方外壳,也是大多数Linux发行版中的默认外壳。在其他没有在基础安装中附带合适的交互式shell的unice上,我认为bash是人们倾向于选择的东西,这是一种自我强化的“ bash无处不在,所以我也将使用它”循环。另请参阅为什么到处都有bash?(具有大量的历史信息)。

  • Zsh具有bash的几乎所有功能以及更多(有用!)功能。它的主要缺点是鲜为人知,这实际上意味着您不太可能会发现它已经安装在其他人设置的系统上,并且与此有关的第三方文档也越来越少。另请参见您使用哪些zsh功能?有哪些特征的zsh和bash的距离,反之亦然失踪?

  • Tcsh曾经(直到1990年代初)是具有最佳交互功能的shell,例如其前身csh。这使得它很流行用于交互式(但不适用于脚本)。Zsh赶上了tcsh,并很快得到了进一步的改善,bash在2000年代初赶上了(可编程完成),而tcsh在过去15年中几乎没有取得任何进展。因此,现在没有理由学习tcsh。

  • 鱼试图比其前辈更清洁。它具有一些简洁的功能(简单的语法,命令行上的语法着色),但缺乏其他功能(无论作者不喜欢什么)。鱼群甚至比zsh还要小得多,因此影响更加严重。另请参见fish和zsh有什么区别?


对于脚本编写,您可能要针对多种语言,具体取决于您希望脚本的可移植性。

  • 任何假装类似于Unix的东西都有一个Bourne派生的shell作为/bin/sh。围绕/bin/sh不兼容POSIX的地方还有一些商业联盟。

  • 几乎每个正在运行的Unix都有一个sh可执行文件,至少与POSIX.2-1992兼容,通常至少与POSIX:2001 aka Single Unix v3兼容。该shell可能位于其他目录中,例如/usr/bin/posix/usr/xpg6/bin。POSIX仿真层也适用于几乎每个功能强大的系统,足以支持它,从而使其成为有吸引力的目标。

  • 许多UNIX系统有ksh93的,这带来的是POSIX SH缺乏一些非常实用的功能(数组,关联数组,扩展水珠(*(foo)@(foo|bar),...),空水珠(~(N)foo*),...)。Ksh最初是商业软件(在某些习惯形成后于2000年免费),许多免费的unices(Linux,* BSD)养成了仅提供缺少许多有用功能的较旧的免费克隆(pdksh)的习惯。。现在,Pdksh在OpenBSD之外已被mksh取代,但是即使mksh也无法实现所有ksh93功能。今天,您不能指望ksh93随处可见,尤其是在以bash为标准的Linux上。

  • Bash在Linux(某些嵌入式变体除外)上始终可用,并且在其他unice上经常可用。它具有ksh93的大多数有用功能,尽管有时语法不同。

  • Zsh具有ksh93和bash的大多数有用功能。它的核心语法更简洁,但与Bourne不兼容。除macOS外,不要指望未安装系统的zsh可用。

  • 要获得更高级的脚本,可以使用PerlPython。这些语言具有适当的数据结构,体面的文本操作功能,体面的过程组合和通信机制以及大量可用的库。大多数unix系统都具有它们,它们要么与操作系统捆绑在一起,要么由管理员安装(因为那里有太多的Perl和Python脚本,因此这是一个罕见的系统,每个系统都没有至少一个)。


4
对于脚本,我以破折号为目标(除非我需要bash的高级功能),该破折号具有最少的功能集,并且是posix抱怨的最大兼容性。(它既小又快)
希尔德·希尔德(Hildred

很棒的纪录片!两个笔记。首先,Solaris是那些“ / bin / sh不兼容POSIX的商业机构”之一。具体来说,它使用jsh不是 Java Shell!)缺少缺少变量替换,例如${VAR#foo}${VAR%bar}
亚当·卡兹

其次,tcsh是谁的〜90年代中期(它见证了双方的前了解到他们的诡计UNIX用户中相当流行的bashzsh),尤其是上了年纪的UNIX + C开发商,谁开始生活csh(提醒,Çcsh看台上的C语言,这是它与bourne样式的外壳区别的灵感)。另请参阅认为有害的Csh编程,我经常将其用作POSIX 深度魔术的提示(除了其反csh参数)。
亚当·卡兹

Mac OS X绝不是“ OS / X”。(:zsh与Bourne有何不兼容?(好吧,除了不进行单词拆分变量扩展之类的东西。)
SilverWolf

@seaturtle不是单词拆分变量扩展是主要区别,如果您尝试使用zsh运行它们,将会破坏许多sh脚本(除非您在sh / ksh仿真模式下运行zsh)。
吉尔斯(Gilles)“所以

27

有两种基本的shell风格:sh(例如bash)和csh(例如tcsh)。对于交互式使用,它主要取决于您的习惯。我已经使用csh,然后使用tcsh多年了,切换会很痛苦,因为我已经习惯了。我也使用过bash,并且我认为没有任何令人信服的理由进行切换。除非您经常使用的计算机上没有其中一个可用。

对于编程,语法是不同的。您不仅可以更改外壳,还需要更改脚本的语法。对于脚本编写,您想使用sh或bash。语法是更适合于脚本,如解释在这里(感谢里卡多·穆里的链接。该是一个很好的指南上的bash脚本。

如果您还没有决定使用Shell,并且希望编写一些脚本,那么我将使用bash来减少需要学习的内容。


12

早在AT&T发明UNIX的时候,就有Steve Bourne编写的Bourne Shell。这是非常基本的,并且缺少当今我们理所当然的许多工具。

AT&T并不是真正从事UNIX业务的公司,所以此时Berkelely采用了非常基本的OS,并且他们对BSD UNIX进行了一些更改。在许多更改中,有一个名为csh的新shell,它对sh进行了很多改进,包括作业控制,更好的交互使用等。不幸的是,他们决定使用sh编程语法,并从C编码样式创建了自己的(有点糟糕)复制的语法。(经典的说法是http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/)因此现在有两种语法。

后来,他们对CSH进行了改进,增加了制表符完成功能和其他一些功能。这变成了tcsh,如果您使用CSH,则可能是您使用的那个。

AT&T认为它并没有完全脱离UNIX业务,因此他们也对其进行了完善。David Korn(好家伙)创建了Korn外壳。基于扩展Bourne shell语法的思想,它为程序员和交互使用添加了很多东西。实际上有一些版本,您可能很少看到ksh88和ksh93之类的东西来表示这些变体。

然后是FSF和GNU OS。他们想制作自己的与UNIX兼容的操作系统,名为Hurd,并希望有一个更好的外壳。他们称呼bash为Bourne Again SHell。POSIX规则进来就在这个时候,他们想使 POSIX外壳。他们环顾四周,从Bourne Shell中获取语法,从Korn Shell中获得改进,并从tcsh中窃取并扩展了交互功能。它已成为Linux上的事实上的Shell,因此非常常见。

还有zsh,被写为“最终” shell。在Linux世界中也很常见。它扩展了bash(并且交叉授粉了一点,一些新东西又回到了bash上)。

如果要选择外壳,我会选择bash或zsh。bash可能比zsh多一些。zsh功能更强大,但是bash对我来说还不错。真正的/ bin / sh Bourne shell只是出于历史原因。bash具有ksh提供的几乎所有功能以及更多功能。该语法比csh或tcsh干净,并且具有比其中任何一个更好的功能。

转换脚本取决于从什么到什么。往返于csh样式(csh,tcsh)的Bourne shell样式(sh,ksh,bash,zsh)将很难。从旧版本升级到新版本(/ bin / sh => bash,/ bin / ksh => zsh)将比其他方式更容易。


请注意,csh-whynot页面是在19959月写回的(请检查顶部的version标签)。我不知道,但是我希望自那以后的18年里,很多事情都会改变。
CVn

8

外壳程序的两个主要分支是Bourne外壳程序衍生物(sh,bash,ksh,ash,yash和zsh)和csh衍生物(tcsh和... uhm ... tcsh)。

我怀疑(尽管我没有实际数字)bash是使用最广泛的,它似乎是大多数linux中的默认shell。

用一个伯恩壳衍生物编写的大多数东西可能会在其他东西上起作用。用Bourne shell编写的大多数内容都可能需要修改才能在csh或tcsh下运行。

就我个人而言,刚开始使用ksh是因为我使用的是系统上的。我现在主要使用bash。


1
fish是csh启发的贝壳
hildred

1

随着时间的推移,我已经使用了许多外壳。并不是什么高级的东西,而是许多需要足够自定义的实用sysadmin和程序设计东西。

我认为zsh具有更多的自定义选项,至少它曾经使用过,但是使用了很多年后,我对它的稳定性和字符编码问题已经足够了。Bash坚如磐石,从未遇到过类似的问题,并且无处不在。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.