有没有理由在 zsh 上使用 bash?

Jas*_*ker 35 scripting shell bash zsh

我很好奇为什么要运行 bash 而不是 zsh。我的意思是 zsh 与 bash 完全向后兼容。不要误会我的意思:我不喜欢 bash 或任何东西。我只是真的想知道使用它是否比 zsh 有任何优势。

那么有什么理由使用 bash 而不是 zsh 呢?

Dav*_*osh 33

想到两个原因:

首先——它几乎随处可用。我有几个没有安装 zsh 的 Linux 系统(在这种情况下是 CentOS 4.x)。同样,我必须接触古老的系统,如 Solaris 2.6 及更高版本、HP-UX 10 及更高版本,以及类似老旧的 AIX 版本。因此,我几乎必须在这些计算机上使用 bash,我这样做是因为我在一个月的时间里接触了数十台(如果不是数百台)个人计算机,并且为了在您的界面中保持一致性,您最终会被困在使用默认值。

其次——它几乎随处可用。这意味着我可以编写一个 bash shell 脚本并且 99% 地确定它在转移到其他地方时会起作用。

是的,这些理由表面上是一样的,但背后的推理却是不同的。

  • 我记得在 HPUX 上有 ksh88/ksh93,我们从来没有权限安装 bash。 (2认同)

Kyl*_*ndt 25

Bash 通常随每个系统一起提供,而 zsh 没有。我喜欢 zsh,但正因如此,我将zsh 用于交互用途,而将 Bash 用于我所有的脚本编写

我发现这让一切变得更简单,因为即使我购买任何兼容 bash 的东西(setopt SH_WORD_SPLIT ?),我仍然会遇到细微的差异。

  • 那将是您指的每个 GNU/Linux 系统? (3认同)
  • 好吧,我发现它带有 OS/X 和 bsd,我对其他 *nix 没有太多经验,他们(最近的版本)通常没有 bash 吗? (3认同)
  • 一定是不同的 BSD:s 那么。至少在 OpenBSD 和 FreeBSD 中,您必须将 bash 与端口/包分开安装。 (3认同)
  • 较旧的 Solaris 版本不包括 bash;我通常不得不依赖 Bourne 作为脚本编写的 shell。这种情况已经有一段时间没有出现了,但是您可能仍然会在一些大企业中遇到它。 (2认同)

Phi*_*l P 13

zsh 不完全兼容 bash。有多种不同。较新的 zsh 与 bash 更兼容(=~ 支持,exec 现在具有额外的标志选项等)但完全兼容不是目标,即使在“模拟”下也不行。

例如,bash 子字符串是 ${foo:offset:len} 但在 zsh 中它是 $foo[start,end] 这只是一个简单的例子。

zsh 是一个受 tcsh 和 ksh 影响的 shell,它以自己的方式做很多事情;POSIX 兼容性显然不是目标,但开发人员会对添加选项/模拟行为的补丁做出响应,使事情更接近 POSIX。但是,当您开始真正了解 shell 的功能时,您就开始创建只写脚本,甚至比 bash 还要多。

bash 是 POSIX sh + ksh + 迂腐,现在从 zsh 复制了一些功能。它也有只写脚本,但因为它的操作符不太强大,所以你最终不会使用 zsh 的简洁性,并且事情可能更具可读性(除了所有避免空格拆分的引用,愚蠢的ksh 风格的 $array 意味着首先-element-of-array,不是数组的所有元素,等等)。

编写充分利用任一 shell 功能的脚本是不明智的,除非您处于受限环境中(例如,编写系统 rc 脚本,其中某些 FS 可能未安装等)。作为一个理想的选择,如果您希望其他人能够维护它,那么将 Perl/Python/Ruby/任何足够大的东西用于您需要 Bourne sh 中没有的表现力的任何东西。保留与交互式 shell 相关的 shell 内容(选项卡完成编程等)。

我不会在 zsh 上使用 bash。对于简单的脚本,我会在 zsh 上使用裸 sh,或者切换到关联数组具有合适运算符的语言(与 zsh 不同,它们再次“简洁”)。如果我需要一个小功能来扩展现有的行之有效的脚本并且现在没有时间重写它,我可能会将sh 脚本切换到 bash。

  • 注意:${foo:offset:len} _is_ 现在支持在 zsh 中,以实现兼容性。 (7认同)

小智 8

我的建议:如果您想要绝对的可移植性,请使用 Bourne shell 规则编写,甚至不要理会 Korn shell 扩展。如前所述,这是一些较旧的“大盒子”,上面根本没有 GNU shell。

Bash 已经“做得太多”了。我有一个朋友在工作,他更喜欢 zsh,但我不知道它到底是做什么的。

无论如何,要么为 Bourne(或“bourne again”)shell 编写,或者,如果您正在为少量特定框编写自定义脚本,请完全跳过“shell 地狱”,只需使用 perl 或 python(或其他您最喜欢的本地安装的解释器是)。


cav*_*ade 5

除了上面给出的可移植性原因之外,另一个原因可能是 bash 仍在添加功能。

例如bash v4.x+引入:

  • 递归通配:

    rm -f **/*.log

  • 自动光盘:

    键入“/tmp”而不是“cd /tmp”

  • bash 如何从 zsh 复制功能成为使用 bash 的理由? (3认同)

小智 5

顺便说一下,您在这里多次被告知 bash 几乎无处不在,所以用它来编写可移植的脚本,这是错误的。

废话。如果您知道您关心的每个系统都有 BASH,那么这是一个完全合理的声明。BASH 有许多有用的特性,这些特性在 POSIX sh 中是无法合理模拟的。轻率地使用非 POSIX 功能不是一个好主意,但是在您真正需要它们时使用它们是可以的。

便携性不是绝对的。就像其他任何事情一样,您需要走多远是有争议的。例如,Fedora 使用 shell 命令来构建 RPM 包,而 Fedora 打包指南规定,由于所有包都必须在 Fedora 上本地构建,因此可以使用 BASH 的所有功能。尽管理论上其他没有 BASH 的发行版可能想要重用它们的源 RPM,但他们还是根据实用性而不是“ALWAYS UZE POSIX!!1”的口号做出了关于可移植性的决定。

ZSH 还没有作为默认 shell 流行起来,仅仅是因为它是一大堆不成熟的想法。

  • 你能解释一下 zsh 中哪些功能或想法是半生不熟的,为什么? (4认同)