我花了一些时间尝试选择一个,在网上比较的是 zsh 与 bash 和 fish 与 bash。但是,我找不到 zsh 与 fish 的任何比较。我用 C 和 C++ 编程,除了 hello-world 类型之外,从未编写过任何主要的脚本。但现在尝试使用 python 和 shell 脚本。哪个外壳首先在生产力方面保留更多汁液,然后是开发?或者最终,任何 shell 的强大功能和可用性都来自其 _rc 文件。那么我对 bash 是否足够好?
4 回答
从历史上看,在 C shell(CSH 和 TCSH)和 Bash 之间存在某种火焰制品。对 CSH 变体的抱怨是它们不利于脚本编写。
在我成为 CLI 迷的这些年里,我从未做过任何选择脚本语言的独立脚本,因为这就是我的 shell。
我写了各种各样的脚本,大致可以分为两类:
- 那些帮助我提高命令行效率的工具
- 那些与我的命令行生产力没有直接关系的。
第 1 类中的脚本几乎总是用我的 shell 脚本语言编写(通常作为函数,因为我使用 ZSH 并且以前使用 BASH,这两者都支持函数)。
第 2 类中的脚本以最有效的方式编写(考虑到开发时间和运行时间)。我经常发现自己用 Perl、C(显然是编译的)、BASH/ZSH/SH 或其他任何我想要的东西编写小脚本。我已经编写了一些 Python 脚本(但不多),有时甚至会使用 Java(再次编译)。
那我在胡说八道什么呢?不要将 shell 的选择基于其独立的脚本功能。选择你的 shell 是因为它对你有用。在您选择的任何其他内容中编写脚本。你可能用 BASH 作为你的 shell 就足够好了(虽然我更喜欢 ZSH,**/* globbing 很好,还有一些其他的小东西,但我为 ZSH 编写的大多数脚本早期都与他们的 BASH 相同同行)。
我有同样的问题,发现:
如果您找不到 zsh 与 fish 之间的任何比较,请自己尝试一下。只有这样你才能知道你喜欢哪一个,没有人能告诉你。另外,定义生产力的含义。对我来说,它丰富的模块和语言的内部功能。如果你已经开始使用 Python,那就去做吧。至于 shell,你可以少学一些(不是说完全忘记它),可能了解你的 rc 脚本和其他系统的东西等。除此之外,Python 可以做 shell 所做的事情。