https://elv.sh/
先说结论：
对于能习惯 fish 的用户建议：别换，比 fish 难用很多，尤其是自动补全功能弱了很多，并非开箱即用
对于连 fish 都用不惯的用户建议：别换，你用不会的
首先对包管理器更新不是很激进的用户有个坑，0.18 对 0.16 的语法不兼容，想用插件的要注意版本问题。
对我来说从 fish 换到 elvish 的主要理由是：fish 已经失去专注交互体验的初心，被用户绑架加了太多兼容 bash 的东西。明明可以直接开个 bash 做的事情。
elvish 主打的是编程语言的体验，交互体验属于次要的，连编辑快捷键都要自己绑。
比如在 macOS 上，fish 能自动处理 path_helper，还支持 source POSIX 风格的 .profile，用 elvish 就需要自己写个两三行配置处理 path_helper 的输入，然后对 .profile 做替換处理以后再 eval。
对于新学一门 shell 编程语言没啥抵触的用户的话，还是挺带感的。
有个包管理器系统，不过因为版本迭代问题，没啥特别有用的插件，还不如直接抄点到配置里。
哦，忘了说了，elvish 支持在 pipe 里传数据结构，和外部程序可以通过把数据结构序列化成 JSON 来交互。
对于编程来说比较棒的是在加载脚本时 elvish 会执行一些静态检查，不至于只有执行以后才能发现错误。
8 个赞
好像rash和elvish的定位差不多? Racket Shell: Rash: The Reckless Racket Shell
5 个赞
不一样，rash 是 embbeded shell，没有交互体验可言
不过看起来 elvish 从 rash 抄了很多语言上的 construct (也有可能都是从 Powershell 抄的)
艹，网站的 favicon 都差不多。看来应该就是 rash 的精神續作了。
不懂就问。你说的交互体验到底指什么呢？能不能举几个例子？
历史记录，命令/路径/参数补全，语法高亮+检查，进程管理，快捷键定制
举个例子，历史记录，前两周试了 ffmpeg 的某个用法想找出来，或者写了一行用来批处理的命令，需要能容易地定位到，并且在一段时间内快速执行类似命令。
补全有 fish 的例子，能做 context sensitive completion，还可以从路径缩写匹配到完整路径，这点 elvish 默认行为不太完善，但是提供了补全脚本的 API。
以前用Chez Scheme写过script用来批处理，感觉就是跟系统交互的API太少了，要不然可以用来做shell了。elvish的API看起来确实要多得多。
另外elvish历史比rash久吧。Elvish – An experimental Unix shell in Go | Hacker News 这个是八年前的讨论。
cireu
2022 年4 月 12 日 17:55
7
应该用 Guile 或者 Gauche, Guile 连 fork 都有，用 Scheme 包装了很多 POSIX API，至于 Gauche
Gauche is an R7RS Scheme implementation developed to be a handy script interpreter, which allows programmers and system administrators to write small to large scripts for their daily chores. Quick startup, built-in system interface, native multilingual support are some of my goals.
就是设计来做脚本的。
关于 Shell, 除开直接用 REPL. Guile 有一个不成熟的 POSIX shell 实现叫做 Gash. 此外 Guix 系统
自己实现了一个功能更少的 Shell 叫做 Bournish， 这个 shell 被嵌入到 initramfs 里面作为 rescue shell（Guix 系统的 initramfs 就是一个静态链接的 Guile）
1 个赞
POSIX 兼容反而是 interactive shell 最不需要的，那些 POSIX API 的绑定连 Haskell 都有，也并不能让 ghci 变成一个 shell 交互环境。说实话都是照着几十年前编程语言没发展起来的老思维设计的，放在今天函数式大行其道反而显得格格不入。
我当年愿意用 fish 的一大原因就是不兼容 POSIX 标准，可以破旧立新，结果 fish 越来越向 zsh 发展了。
至于 POSIX 兼容的 shell，有 dash 就够了。
1 个赞
兼容POSIX标准是有现实意义的。个人用无所谓，但是公司内部，或者组织内部有太多的隐性的环境变量，你要工作就得source很多shell script。没有兼容性根本没法工作。所以既要又要。。。
在公司工作中，不用bash或者zsh基本就是死路一条
9 个赞
LdBeth
2022 年4 月 13 日 03:34
11
exec 进一个 POSIX shell， source 完，再 exec 回去
或者 login shell 用 POSIX shell，在 rc 里完成设置后最后起动 interactive shell。
或者用脚本处理 POSIX shell printenv 命令导出的变量。
只有从网上抄脚本的水平才会觉得这是什么大问題。
其实这个要看什么场景，工作场合，确实要大家保持一致， 原来做系统工作的时候， bash 和其他高级 shell 在解析一些语法的时候确实会不兼容，特别是服务器环境弄错就是丢数据灾难。
个人用的时候，其实还好，更关注高级功能，即使有不兼容的问题，其实都还好解决。
LdBeth
2022 年4 月 13 日 03:56
13
实际上我也不推荐在工作环境装些花里胡哨的东西，一来装起来不便，二来也不安全。个人的环境就可以怎么有创意怎么来。
是的，fish最开始还是很牛逼的，兼容确实会束手束脚。
事实是，没有人在乎 bash 脚本语言了。fish 和 omz 能流行起来，是因为交互体验做的好，而非语言上的改进。语言上的小修小补，改变不了它不上不下的尴尬境地。
很多人仍用 bash 的唯一原因是，它是内置的，兼容的。所谓的改进把兼容性拿掉，它很快就会死。
不如关注一下 fzf、lazygit 这类交互应用，以及终端模拟器方面的创新，比如 alacritty、wezterm 还有 wrap。
生产环境只有bash。zsh、fish是什么，从来没见过，也装不上去，海量的机器装也装不完。
2 个赞
我也想要一个新的shell，主要是想要一个高效处理文本的工具。bash 写的有点痛苦。
LdBeth
2022 年4 月 13 日 14:12
18
取决于你处理的是什么文本，我有 SNOBOL，CRM114，ML1，TECO 可以选，或者 Common Lisp + PPCRE，APL 这样的也行。
LdBeth
2022 年4 月 13 日 14:36
19
顺带提一下，虽然好像没人发现，elvish 是“国产编程语言”，作者在知乎有账号。
至于 bash，在 macOS 上很快就会淘汰了（果子不太可能更新到 GPL3 的版本，现在的 GPL2 版有很多安全性问题），在其他 BSD 上也根本不在预装程序里，很多 Linux 都开始用 dash 取代 bash。
fish 和 zsh 的用户是建立在社区贡献大量配置脚本上的，当 power user 发现社区能提供的脚本不能贴合个人需求的时候，想写自己的脚本，发现这脚本语言还非常烂，就会有 elvish 适用的场景，elvish 作者就是前 fish 贡献者之一。
另外一个场景是，shell 写复杂的命令常常需要 awk 和 perl，相当于同时掌握三门语言才能把一件事做好，从 scheme shell 开始就有人研究如何把日常脚本需求统一到一个语言里了，elvish 算是摘果子了。
顺带 elvish 现在已经集成了类似 fzf 的搜索界面和类似 ranger 的文件管理器，作者的表示等 1.0 以后就坚持下个十年不会加编程语言特性，专注在 UI 功能上，所以现在才专注在语言设计上。
3 个赞
如果我没记错，elvish最早用的就是lisp的syntax，只是去掉了最外层的括弧。