是否建议使用 zsh 而不是 bash 脚本?

Pro*_*sch 28 bash zsh portability shebang

我可以假设已经zsh安装了足够多的人来运行带有

#!/usr/bin/env zsh
Run Code Online (Sandbox Code Playgroud)

作为舍邦?

或者这会使我的脚本无法在太多系统上运行吗?

澄清:我对最终用户可能想要运行的程序/脚本感兴趣(例如在 Ubuntu、Debian、SUSE、Arch 等上)

Sté*_*las 31

为了便携性,没有。虽然zsh至少可以通过 Cygwin 在任何 Unix 或类 Unix 甚至 Windows 上编译,并且为大多数开源类 Unix 和几个商业版本打包,但它通常不包含在默认安装中。

bash另一端安装在 GNU 系统上(就像bashGNU 项目的外壳一样),如绝大多数非嵌入式基于 Linux 的系统,有时也安装在非 GNU 系统上,如 Apple OS/X。在商业Unix侧,在Korn shell(在AT&T的变体,但更多的ksh88一个)是常态和双方bashzsh都在可选包。在BSD系统,首选交互shell往往是tcsh同时sh基于要么Almquist外壳或pdkshbashzsh需要安装的可选包为好。

zsh默认情况下安装在 Apple OS/X 上。它甚至曾经是/bin/sh那里。默认情况下,它可以在一些 Linux 发行版中找到,例如 SysRescCD、Grml、Gobolinux 和其他可能的发行版,但我认为没有任何主要发行版。

与 for 一样bash,存在已安装版本的问题,因此存在可用功能的问题。例如,找到带有bash3或 的系统并不少见zsh3。此外,不能保证您现在编写的脚本zsh5可以使用,zsh6尽管bash它们确实尝试保持向后兼容性。

对于脚本,我的观点是:使用 POSIX shell 语法,因为所有 Unices 都至少有一个 shell sh(不一定在 中/bin)能够解释该语法。那么你就不必太担心便携性了。如果该语法不足以满足您的需要,那么您可能需要的不仅仅是一个 shell。

然后,您的选择是:

  • Perl 无处不在(尽管您可能不得不再次将自己限制在旧版本的功能集上,并且不能对默认安装的 Perl 模块做出假设)
  • 指定解释器及其版本(python 2.6 或更高版本、zsh 4 或更高版本、bash 4.2 或更高版本...),作为脚本的依赖项,通过为每个指定依赖项的目标系统构建一个包或通过规定它在与脚本一起提供的 README 文件中,或作为注释嵌入脚本顶部,或者在脚本开头添加几行 Bourne 语法,以检查请求的解释器的可用性并以显式错误退出如果不是,就像这个脚本需要 zsh 4.0 或更高版本
  • 将解释器与您的脚本一起发送(注意许可影响),这意味着您还需要为每个目标操作系统提供一个包。一些解释器通过提供一种将脚本及其解释器打包在单个可执行文件中的方法来简化它。
  • 用编译语言编写它。同样,每个目标系统一个包。


von*_*and 9

你不能。保证可用的是/bin/sh,本质上是原始的 Bourne shell。几乎所有(注意“几乎”!)Linux 安装都会有 bash,但在 *BSD 系统上很少见(BSD 对 GPL 代码有严重的疑虑,如 bash)。我不知道 Mac 上的标准 shell 是什么,但同样,对 GPL 存在疑虑。对于 Solaris 也是如此。

zsh 是一个小众 shell,它不在 Fedora 的默认安装中(我不相信它是任何主要发行版的默认设置)。

  • 当然不是原始的 Bourne Shell,而是 Posix 兼容系统上的 Posix shell,在许多系统上是 /bin/sh,但不一定如此(在 Solaris <= version 10 上,这是 /usr/xpg4/bin/sh) (7认同)
  • @StephaneChazelas,“小众”,如“很少有用户使用它”/“很少有安装拥有它”。它可能是自切片面包以来最好的外壳,但如果只有一小部分使用它,你不能指望它会安装在任何地方。 (2认同)