zsh和emacs'(e)外壳的优缺点

关于 M-x eshell :

1. eshell不是一个独立的shell;它是在纯elisp中实现的,因此不能在emacs之外运行,这就是它不是标准shell的原因。它没有自己的脚本语言,比如bash/zsh/etc;它有elisp和一些命令解释工具,可以让调用elisp变得更干净。

2. 我不能和zsh和eshell说话,但我主要是从bash转到eshell。95%的时候,埃塞尔做我想要或需要的一切,没有任何问题。我不把它用于ssh。而且,一旦一个进程启动,就不能对其进行后台处理(但可以在后台启动它)。

3. 这将非常困难,因为zsh有完整的脚本语言,而eshell基本上是elisp解释器的接口。你在一个交互式外壳中寻找什么?埃塞尔可能能做到大部分。命令行上的条件语句和循环?当然。别名、函数、通配符、可编程完成?当然。

4. 我的迁移方式基本上是从头开始。每当我遇到我不喜欢或希望看到的事情,我就会想办法让它做我想做的事情。例如,eshell使用pcomplete.el进行可编程完成,因此添加完成功能非常容易。

5. 与Emacs的集成对我来说是一个巨大的胜利。可以让elisp函数通过管道连接到shell命令。举个愚蠢的例子,试试:

   message "hello world" | cut -f 1 -d ' '

   有些命令(尤其是grep)被放在emacs缓冲区中,因此您可以快速跳转到结果。

6. 取决于你在emacs上花了多少时间。如果你这样做了 一切 在Emacs中,它很有用,因为有时通过eshell将elisp命令与其他命令连接起来更容易。如果您发现自己在Emacs和shell之间复制和粘贴的频率太高,那么这可能不会是一个胜利,您必须花时间定制它,使其达到您满意的程度。

作为埃塞尔的替代品, M-x shell 运行您的普通shell,在其下解释所有命令(因此不能访问elisp函数),而命令行编辑(因此可编程完成、历史记录等)由emacs完成。我用它来做ssh。

另一种选择是 M-x term 它是Emacs内部的终端仿真器,通常在底层运行shell,shell完成所有正常的工作。那么,完全不需要转换/适应步骤。

不同的语法

自从 eshell 允许混合 elisp 使用shell命令编写代码时,它有一些非常不寻常的语法,您需要小心。

需要注意的一点是命令扩展的语法: zsh 使用语法

file $(which foo)

但在 埃斯尔 这意味着basicaly和

file (which foo)

这意味着运行 file 对ELISP表达式计算结果的命令 (which foo) ,这通常会导致如下错误:

Symbol's function definition is void: which

file ${which foo}

便携性

自从 埃斯尔 它是用平台无关的EmacsLisp代码编写的,在Windows本机Emacsen上的工作方式与在*nix上的工作方式基本相同(当然,您可能需要 coreutils 和类似的);获得 shell-mode 要想和尼克斯的空壳合作,可能至少会有点棘手。

我认为我已经看到了一些完成绝对路径的奇妙之处,尽管,因为驱动器号后面的冒号,但这并不是一个真正的节目阻止器…

我认为你所有的6个问题都可以翻译成一个问题: 所有事情都可以在zsh中完成 Emacs ? 答案是 对 还有更多。我不会说shell,eshell或者其他一些emacs的模式,我只是说 Emacs .

Shell,eshell只是Emacs的模式,如果我能找到一种方法或模式,至少在这种方法或模式下,zsh可以做任何事情,所以它回答了你的问题。方式是 ansi-term 在Emacs模式下,它可以在Emacs中完美地运行zsh,如果无法在shell或eshell中执行任务,则可以切换到 ANSI术语 Emacs中的模式,所以您的问题消失了。

eshell 刚刚消失 shell 而那些不擅长交互/滚动命令,例如 top , less 等。