我使用过 bash、csh 和 tcsh。但我问了this question，乔纳森告诉我 csh 不值得信任。那么什么样的 Linux shell 对开发有好处。为什么？
【问题讨论】：
到目前为止，Linux 上最常见的 shell 是 bash。除非您有充分的理由使用替代方案，否则我建议您坚持使用 bash，或者您的项目团队最常用的 shell（或者您必须使用的大部分 shell 脚本）使用。
另一个非常常见的竞争者是 dash，它被 Ubuntu 项目越来越广泛地使用。
这真的是个人喜好，好吧，除了csh。
【讨论】：
csh 不再有效，但这个链接有效：grymoire.com/unix/CshTop10.txt
我更喜欢 zsh。
单是制表符完成就值得了：
【讨论】：
为了交互性，使用 Zsh。有一段时间我是 Bash 选项卡完成脚本的 FreeBSD 端口的维护者，但在我第一次尝试 Zsh 时就放弃了它。它可以做 Bash 可以做的所有事情，但更轻松、更优雅。它还具有非常类似于 Bash 的击键的好特性，因此，如果您在没有 Zsh 的系统上，您将能够做到（即使它不会“感觉”那么好）。
对于脚本，请使用 Bourne Shell (sh)。它是 POSIX 标准脚本语言，您的脚本几乎可以在任何地方工作。 Bash 和 Zsh 以及其他 shell 具有不错的扩展，您会错过这些扩展，但它们会将您绑定到特定的设置。对于您确定永远不会在其他地方运行的仅供个人使用的脚本，请忽略该建议，但请记住，这是您需要考虑的真正权衡。
但总而言之，Zsh。我不知道任何尝试过的人没有立即永久切换。真的那么好。
【讨论】：
Fish（友好的交互式外壳）是大多数其他外壳的不错替代品。它具有一致的语法、良好的制表符补全和语法突出显示，易于上手和使用（尤其是如果您没有使用其他 shell 的习惯），并且具有出色的运行时帮助。
缺点是它的开发不规律，用户群很小（但很有帮助），并且与其他 shell 非常不同。与 shell 习惯用法的向后兼容性不是优先事项。
在很多情况下这很好...很多标准的 shell 有非常愚蠢的做事方式，只是因为它一直都是这样做的。 “做/完成”、“案例/esac”、“如果/fi”？这是鱼会消除的精神错乱。
值得一看。
【讨论】：
既然我相信我是建议你应该使用 C Shell 以外的东西的人，也许我应该稍微修饰一下我的言论，然后支持那些说“Linux 上的 bash，其他平台上的 Korn shell”的人（除非bash 也安装在那里）'。
比较像编辑器（你更喜欢vim 还是emacs），shell 的选择部分是熟悉度问题，部分是偏好问题。有很多人喜欢 C shell，尽管我确实相信它不如 Bourne shell 和衍生工具那么容易编程。我在 .cshrc 中的内容确实等同于 exec /bin/ksh（这并不完全相同，因为我想执行一个登录 shell - 一个读取配置文件的 shell 等等），但我不会谴责任何人如果是明智的决定，则使用 C shell 或衍生工具。
如果你决定要使用 C shell 以外的东西，那么你基本上属于 Bourne shell 阵营，POSIX 标准或多或少地指定了预期的行为，然后是不同的 shell——也就是说， Bourne、Korn 或 Born Again shell——添加（或者，在经典的 Bourne shell 的情况下，减去）一些功能。如果您的代码可能需要从 Linux 迁移到 HP-UX、Solaris 或 AIX（经典的 AT&T 派生的 Unix 变体中幸存的三重奏），那么您应该考虑确保使用经典的 Bourne shell 编写 shell 脚本，尽管 Korn shell 也很安全。但请注意，在 Linux 上您可以编写 #!/bin/sh 并获得 Bash，在其他平台上，您将获得 Bourne shell。
我在 Korn shell 和 Bash 之间切换没有大问题 - 很少有小问题。我倾向于避开这两种语言中没有明确定义的那些角落——这往往意味着“在两者中都有定义”。对于那些使用 Linux 的人来说，另一个问题是 GNU 工具比经典的 Unix 版本有更多的选项，并且您可能会失去可移植性，这不是因为您使用的 shell 编程结构，而是因为您使用的命令选项。经验丰富并随时可以访问其他系统的手册页会大有帮助。
【讨论】：
我通常坚持使用 bash，因为它比直接 sh 更友好，而且它是我半定期使用的每个发行版（SuSE、RHEL、Ubuntu、Slackware）的默认设置。
但是，如果您打算编写可移植的 shell 脚本，请确保它们都在 real sh 中运行。
【讨论】：
重击。这是标准的。
【讨论】：
如here 所解释的，csh 的问题在于它对脚本编写很垃圾。没有真正的理由不应该将它用作交互式 shell，但是大多数人发现学习两个不同的 shell 并且不能在命令行上尝试他们的脚本部分会让人感到困惑，所以使用它是最简单的一切都一样。
交互式 shell 的明显候选者是 bash、dash、zsh 和 {pd,}ksh。所有这些都实现了 posix shell 标准，并带有一些小的扩展。选择你喜欢的交互式使用，我倾向于使用 bash，因为它是 linux 上的标准，但它们都有其优点，特别是 zsh 似乎很受欢迎。
如果您要编写一个可移植的脚本，请使用 #!/bin/sh，并确保使用标准 posix shell 语法。如果它适用于 bash 和 ksh，它可能是标准的。有一些旧版本的 unix 有一个非标准的 /bin/sh 但除非你知道你必须这样做，否则我不会为此烦恼。更多的可移植性问题是您从脚本中调用的所有命令行工具。
【讨论】：
没有人提到 sh 的基于 Debian 的标准，它是 Debian Almquist shell dash。它完全符合 POSIX 标准并且启动速度非常快，这就是 Debian/Ubuntu 将它用于/bin/sh 的原因。
所以我将bash 用于我的交互式shell，但仅dash 用于脚本。这样我就知道我的脚本至少符合 POSIX，并且可以在任何其他 POSIX shell 上运行。 ...我知道可移植性不仅仅是外壳，而是我划清界限的地方。
【讨论】：
我不是 Ruby 大用户，但 http://rush.heroku.com/ 看起来很有趣
【讨论】：
坚持使用 bash 可能是最好的，因为它是最广泛使用的 shell，并且您可能从某人那里获得的任何教程或帮助很可能会使用 bash。但是，我已经开始在我的所有脚本中使用 zsh，并且我发现它在脚本方面远远优于 bash。
【讨论】：
不要使用 Korn Shell (ksh)。
除非你打字很完美，而且永远不需要使用退格键。
【讨论】：
其实我喜欢 ksh。它比 bash 更一致，因为它不尝试支持任何 csh 构造。根据我的经验，tcsh 与其他 shell 的兼容性最低，我避免使用它。我尝试为 sh 编写脚本，但 ksh 确实具有一些不错的功能，例如在一行上导出和设置变量。我也尝试保持与 bash 的兼容性，因为它功能齐全且很常见。要编写可移植的 shell 脚本，这比选择“最好”的 shell 更重要，你可以参考这本书。
便携式 Shell 编程：Bruce Blinn 的 Bourne Shell 示例的广泛集合（HP 专业系列）（平装本 - 1995 年 10 月 29 日） amazon.com
【讨论】：
我一直在使用 pdksh，没有任何接近完美的打字（也许您需要修复您的 termcap？）。
ksh 是标准，csh 是标准，bash 是“标准”，但仅限于 linux。最好以 ksh 为目标。
【讨论】：
对于编写实际脚本，我更喜欢ksh，它有几个对编程有用的扩展并修复了one of my pet annoyances。
bash 是我对交互式会话的偏好，但这更多的是个人偏好问题。只要确定它是一个 Bourne 类型的 shell。
【讨论】：
我也是从 csh、tcsh 到 bash。它有所不同，但经过一段时间后，至少和 c-shell 一样好。
对于脚本，我建议使用 ksh，因为它在大多数 Unix 上都可用（Solaris、HP-UX、OSF/1（有史以来最好的 UNIX ；）——现在是时候了））并且它具有很好的特性。使用 Korn，您可以对大多数脚本进行编程。偶尔你想得到比一个数字更多的值，作为函数的返回值，或者你有一些你不能放在一个简单数组中的数据，或者你需要一些在正则表达式的情况下具有更好功能的东西，或者其他什么，那么我会建议perl。
【讨论】：
对于脚本，请尝试使用 dash 一段时间以更好地了解可移植性。如果你曾经使用 bash 编写过 shell 脚本，请在脚本 shebang 中显式声明 bash。
为了您的个人控制台使用，请尝试现有的内容。找到你觉得舒服的东西。选择一个必须从源代码编译的 shell，用于您关心使用它的每台机器，让您的所有系统管理员朋友变得古怪并惹恼您。
【讨论】：
我认为 FISH 是最好的，它有语法高亮（对于不存在的命令）并且可以自动填充。而且很容易学。
【讨论】：
选择一项： 一种。 tcsh 湾。克什 C。 zsh d。登录 e.重击
我会使用登录。只是在说。
【讨论】：