Take Two: Eshell
43 comments
·July 3, 2025ndegruchy
cmrdporcupine
Yes it may be the case that the achilles heel of Eshell is that it tries to be too bash-like. Just making it clear that this is an "elisp thing that interacts with both emacs and your system" and call it "dialog" or "interactive scripter" or something and dispense with following normal shell conventions (while still offering tab completion etc) might have been wiser.
imiric
I've been using Emacs daily for well over a decade now, but I just can't get myself to use any of its shells, or features that replace standard shell workflows.
I think the main reason—besides muscle memory and the scripts, aliases, and commands I'm already used to—is because a POSIX-compliant shell exposes a generic interface for both programs and users. Programs can receive and output data over standard file descriptors. They have a CLI with common design conventions regarding flag and argument parsing. Some programs choose not to follow these conventions, and some have a very complex CLI, but for the most part users can expect a specific interface to exist. Man pages have a standard format, and way of accessing them for all programs. And so on. All compliant shells on Unix-like systems work in a similar way, which means that the workflows I'm already used to are easily transferrable to any other system.
Contrast this with the workflow table in TFA. It's a mishmash of different Emacs modes, each with their own quirks, UI, and ways of interacting with other modes. One could say that Elisp ties it all together, but it's a general purpose programming language which obviously doesn't enforce a cohesive user interface for packages to follow. Eshell even complicates this because it resembles a POSIX shell, but doesn't follow any Emacs interface guidelines, so it breaks conventions of both sides. Sure, I could force myself to learn the intricacies of each package over a long time, and create a cohesive Emacs configuration that works for me, but I would need to lug around that configuration and depend on Emacs for everything. Which I'm sure Emacs purists would claim is the way to go, but I don't like that. The beauty of Unix systems is the ability to easily replace any tool in your workflow without impacting everything else. For example, I've mostly replaced `ls` with `eza`, `grep` with `rg`, `find` with `fd`, `top` with `btop`, etc. These were essentially drop-in replacements with minimal impact to me. Consider what it would take to replace dired or Magit, as perfect as they might be.
The Unix "small programs that do one thing well" philosophy is often ignored, unfortunately. Emacs might be the single biggest offender of it, though I suppose it's to be expected since "GNU's Not Unix"... The benefit of it is precisely the flexibility it gives to users. As much as I love Emacs, I'm not married to it, so relying on one special program that does many things would be harmful for me in the long run if a better alternative appears in the future.
skydhash
> These were essentially drop-in replacements with minimal impact to me. Consider what it would take to replace dired or Magit, as perfect as they might be.
There's a difference of philosophy there. The Unix way is a good concept to align software, but it's not the only one. In Emacs, the primitives are different. Instead of having pipes, redirectors, thinking in terms of lines,... What you have are buffers, windows to displays those buffers in, frames to hold those windows, a lot of functions to manipulate the text in buffers and keybindings to activate those functions. There's also the minibuffer for input and the echo area for messages.
So using those people creates packages that solve each a particular task. But the packages are not closed programs you compose together. They are both libraries and a particular way to use the library. If it does not fit your purpose, you alter it. If it's missing something, you add it. If your workflow requires two or more packages, you link them together, creating a metapackage for that workflow.
So Emacs is something to mold to your own needs. The default configuration is just the most common and the traditional way to do stuff. It's not lego bricks like the Unix way, it's clay. You don't replace ls with eza, you turn ls into eza.
imiric
Right, the primitives are definitely different. But that's my point. The Unix primitives are simple and generic, which allows the user to quickly and easily adapt a disparate set of tools into an infinite number of workflows. The user is not required to also be a programmer[1]. If they are missing a specific tool, which is very rare, then it can be written in any language and integrated into existing workflows by following the simple design conventions. This generic interface is why programs written decades ago are still useful today. They don't need to be aware of how they're going to be used. They just need to follow the established design conventions.
In contrast, if a specific Emacs package doesn't do what the user needs, they must use Elisp to change it, or write their own package. Integrating packages in a cohesive workflow also requires programming, and each integration is special because every package has its own quirks and API. This might be second nature to some Emacs gurus, but I don't want to program whenever I need to change my workflow. I'm sure that I could eventually build the perfect operating system for me this way, but I'd rather rely on an extensive ecosystem of tools written by others.
[1]: I would argue that shell scripting is not programming, for better or worse. It's often the best tool for the job for getting things done quickly, but for more sophisticated tasks a programming language is a better fit.
skydhash
Emac's primitive are much more involved for sure. But the focus on having a simple and common representation for input and output instead of the separation between prompt and output has make it a lot easier to write involved tooling. Instead of a TUI application which breaks the unix philosophy or a script for a single workflow, you have both. The closest I think is now Vim+tmux, but it's now as easy to modify on the fly.
pama
I use a personally-adjusted variant of M-x shell for most of my last 20 years of Emacs use (after trying various hacks including things mentioned in this article). I end up having about 20–100 named shell buffers on each machine, different projects, logs, etc, and I keep all histories of each shell in separate history files. It helps that the buffers are practically infinte size and I can use standard Emacs editing for anything, plus comint, which is a great simple interface to shells. I have some tools to split the Emacs frame into multiple pieces and reorganize them quickly so I can see any number of my open shells, limited only by the monitor size. I dont understand how people live without such shell management solutions; I’ve seen expert tmux users struggle with keeping track of all shells, whereas Emacs has tons of tools to work on buffers that directly work: starting from simple ibuffer, bookmarks, previews, to multi-occur (which can specialize to shells or subsets of them), to whatever you wish to do with buffers really.
btop/htop/nvtop or other curses-heavy tools have specialized solutions (open vterm or eat and run it), but all the composing unix tools run in M-x shell.
marai2
I think if you were to write a post (or better yet a video) to demonstrate your usage of your workflow, that would be a great resource! I love working in M-x shell but your workflow sounds next level.
em500
> The Unix "small programs that do one thing well" philosophy is often ignored, unfortunately. Emacs might be the single biggest offender of it, though I suppose it's to be expected since "GNU's Not Unix"...
It's not because of GNU (which is a Unix workalike), but because Emacs originated on ITS and Genera Lisp Machines, which were truely very non-UNIXy environments.
imiric
Ah, that makes more sense. I'm not very familiar with the history.
null
vkazanov
I am well past the phase of trying to pull everything into emacs. All reasons to not use eshell you mention are valid, and I can add one more: vanilla eshell doesn't really work well with visual commands.
But recently I installed eshell-eat, and my biggest paint point just went away.
I never expected to use eshell as a full-blown terminal replacement. I use half A dozen aliases (find-file dired...) , some lightweight lisp scripting, git that, apt install there... That's about it.
In that capacity it's a valid quick tool.
adalacelove
spauldo
I never understood the need to do everything in Emacs either. I love Emacs, and I use it for all kinds of things, but the UNIX ecosystem has great tools too and it seems silly to have to choose one or the other.
Calling shell commands from Emacs and inserting their output into a buffer is great, don't get me wrong. But Emacs' terminal experience pales in comparison to plain ol' xterm.
At the end of the day, I use the tool I'm most comfortable with and does a good job. Sometimes that's Emacs, sometimes it's not. Maybe if I hadn't spent 20 years in the shell before picking up Emacs I'd feel differently.
eschneider
There _used_ to be a huge advantage to pulling everything into emacs rather than having to background emacs, do whatever, then bring emacs back into the foreground. With multiple windows or multiplexers like tmux/screen, it's a lot less necessary, but still nice.
michaelcampbell
> But Emacs' terminal experience pales in comparison to plain ol' xterm.
[lib]vterm reduces this paling to almost zero.
noufalibrahim
I agree. I do have a bunch of aliases that allow me to send the output of a command into an Emacs buffer, that open a file, open a file as root, open a file on a specific line and things like that which smoothen out the flow. However, I'm much more comfortable in the Emacs+Terminal environment than in pure Emacs.
michaelcampbell
vterm takes care of at least the vast majority of the display issues that emacsian shells typically suffer from. It's literally a shell as a buffer. htop and other curses based TUI's seem to run fine in it.
I mean do what works for you of course, but I found it a vast improvement over the historical emacs shell things, which I've also used for decades.
johnisgood
eshell:
Welcome to the Emacs shell
~ $ btop
ERROR: Failed to get size of terminal!
~ [1] $
$ btop
Terminal size too small: Width = 79 Height = 22Needed for current config:Width = 80 Height = 24
ansi-term:
Same as shell.
Any other Emacs shells I missed?
In any case, I do not use any shells within Emacs. I use XTerm separately.
skydhash
Visual programs won't work within emacs standard shell interaction. Only line oriented programs works (printing one line at a time and exiting). But for many visual programs, you have the equivalent in Emacs.
kreyenborgi
For interactive stuff you probably want eat https://github.com/kephale/emacs-eat or vterm
(I don't use them, I prefer my shells to last even if I should restart emacs)
michaelcampbell
johnisgood
Does it have to be the GUI version of Emacs?
unixhero
The writer is incredibly knowledgable. But all of this is completely unapealing. To me this isn't power, it is just learning a lot more things.
wwarner
I liked all the parts that were not about eshell. Wdired and its cousin wgrep are killer. I didn't see much value in the eshell examples provided.
fn-mote
The power comes from the ease with which you can adapt your workflow to varying requirements.
If this description doesn’t cover areas you need to work in, forget it.
An example: you need to do a bunch of work in a pipeline, but at one point during development you want to stop, examine the output, possibly edit it, and then finish the pipeline. In this case, doing the work in emacs feels good because you can put the intermediate results in a buffer. Not life changing, but nice.
cmrdporcupine
Every few years I put time into learning eshell and it's seriously impressive.
But what I really want is eshell outside of emacs. In fact I want all the bits of emacs outside of emacs.
The problem with eshell is the problem with emacs. It's a monolith. I know I know that's also its strength, but what I really want is for all the bits of emacs to be exploded out into components that make up an overall environment (yes, yes, Genera/Lisp Machines).
Unlike emacs purists, I am too much in and out of that environment to really ever feel fully comfortable adopting all its tools as my mainstay tools.
log101
I wish someone could write a "The Good Parts" book for Emacs. Even after reading the manual twice, I'm still overwhelmed with the API and forget even the most basic configuration options after a month of inactivity.
mystifyingpoi
I have the same feeling with Vim after using it for like the past 10 years professionally. Granted, it is much smaller, but for instance editing multiple files using just stock config is surprisingly undiscoverable. It comes with the whole buffer mechanism, which is certainly powerful, but I guess that 99% of newcomers just want to open tabs and go left/right, not to learn set of byzantine commands like :rewind or :last.
At this point, I believe that newcomers should jump straight to Neovim and file manager plugins, than deal with the stock stuff. That's just one thing out of many.
senkora
I did find the Vim manual to be a high-value read for basic editing, for what it’s worth.
It’s pretty short and I felt like most of it was useful.
ethan_smith
Doom Emacs (https://github.com/doomemacs/doomemacs) essentially serves this purpose with its curated, modular configuration and excellent documentation that focuses on the most useful parts while hiding complexity.
kstrauser
Doom is really cool and I appreciate the devs’ hard work. It’s seriously impressive.
But. Doom is an uncanny valley for me. It looks like Emacs, but feels like something else entirely, something unlike I’ve ever used before. If you want to use all the things available inside Emacs without learning the “bare” version, right on. But if you actually want to learn Emacs, in my opinion, Doom isn’t it. It’s its own thing, and it’s a fine thing, but whatever it is, to me, it ain’t Emacs.
kqr
I'm not sure that'll happen, because Emacs itself is not so much end-user software as it is a platform/VM for developing and running Elisp code.
There are many great applications and compatibility layers written to run on Emacs:
- Evil for a decent editor,
- calc for a good, flexible calculator,
- magit for version control,
- smerge for conflict resolution,
- dired, org, notmuch, tramp, eshell, outshine, comint, htmlize, etc.
and each of them deserves a "the good parts" book!
agumonkey
There's truth to this. Emacs is large. I tried RTFM twice, thrice .. not skimming, taking time. And even then I learn later that there was some feature in it that I completely missed. And it's a common joke in the community "I've been using emacs for <N> decades and I didn't know that...".
Blessing and a curse ? Maybe they should rebrand emacs as a universe and not an editor.. so that people know there are many galaxies to explore
imiric
The thing is that you don't really learn Emacs. Emacs is just an interface to programs written in Elisp that happens to have editor-like functionality out of the box. There are specific conventions it follows, and Elisp has its own set of quirks and a steep learning curve if the user is not fluent in other Lisp languages, so those can be challenging to learn. But boiled down to its core, there's not much to Emacs itself. It's actually a pretty bad editor OOB, but that might be subjective.
What is more challenging is actually customizing Emacs to suit your own preferences, which is the main reason you would want to use it. Deciding which external packages to install, how to use and customize them, and writing your own packages. That is a lifelong endeavor and learning experience, just like programming. So it's to be expected that someone might be a long-time Emacs user, but not be aware of some of its features. You're not expected to know everything, nor do you need to. Just learn as much as you need to make it useful for you. Essentially, every Emacs installation is different, since it's purpose built for a specific use case according to very specific preferences. There's no singular "Emacs". And that is a beautiful thing. :)
agumonkey
I was really talking about the builtin libraries (listed in the core manual). That in itself is a challenge. The surface is huge. Not a critic per se, I've been using emacs for 25 years, I'm just reporting.
spauldo
Generally speaking, unless you're doing something weird (typeset IEC ladder!), proprietary (code completion for Aveva Quickscipt!), or right on the cutting edge, someone has figured out a way of doing what you need in Emacs. You just have to identify the pain points first. That's harder than people think.
spauldo
Emacs is the type of environment you need to immerse yourself in and build an intuition for. There's no shortcut for that. If you can't spend a couple hours a day for a few months using it, you're never going to feel at home in it.
It's quite possible you just don't need Emacs.
wwarner
As a longtime emacs user, this perfectly summarizes what is most awful about it! It makes me cringe when people wag their fingers to correct the "misperception" that emacs is merely a great text editor and IDE, but rather a programmable elisp application platform. In reality, vanilla emacs with only a little bit of configuration (and as with any other editor, substantially more tinkering with installation and configuration of supporting binaries), provides a really great programming environment for almost any type of application.
noelwelsh
I would install Doom Emacs and go from there. It presents all the good bits in a (mostly) coherent whole.
vkazanov
No matter you do, inactivity means forgetting. Why do you need the api memorised if you don't use them?
I mean, using the editor itself means maybe 10-15 keys/commands.
Mastering Emacs is a good overview, btw.
gray_-_wolf
Yeah, the book is definitely worth the asking price.
I feel like most folks misunderstand Eshell when going into it. It's not really their fault, as they _expect_ something bash-like, and in many ways it is. However, Eshell is _not_ bash. It's not zsh. It's not fish. It's Eshell. When you use Eshell, you get a marriage of command-line tools and Emacs. This isn't always the best case, and some tools are awful to try and use in Eshell.
Eshell shines when you're looking to use Emacs to do stuff in the shell, but not really deal with the shell itself. It will dutifully run whatever program you feed it, but the real magic is when you want to deal with the output. You can redirect outputs to buffers, which you can then manipulate with Emacs familiarity. You can even handle remote sessions just as easily as you would open a remote file in TRAMP. I've used this on many occasions to edit a remote config file, then trigger Eshell, which puts me in that directory, to then restart the service without having to launch a separate SSH session or terminal.
While there are a lot of clunky bits of Emacs, I feel like Eshell gets an especially bad rap. Some of it's justified: It presents itself as a bash-like interface, while actually having vastly different ways of handling things. I feel like folks don't really get the idea that it's an interactive Emacs session, a worksheet for the command-line that lets you ingest data from external tools in a more ergonomic way than doing `shell-command` or similar.