Thursday July 31 2025

Hacker Times

Take Two: Eshell

Listen to this article (with local TTS)

This is a contribution to the Emacs Carnival 2025-06: Take Two collection of posts on Christian Tietze’s blog.

My first take with Eshell many years back did not leave a good impression. My early expectations was that it should act like any other shell, only to be unpleasantly surprised by it. It took a long time for me to warm up to Eshell. Upon reflection, it was because I wasn’t ready for it.

Now Eshell is an inseparable part of my Emacs experience. Paradoxically though, I find little occasion to use Eshell in the same way I’ve used shells in the past. Much of what I used to use the shell for, I do today with Emacs modes instead.

It was not always this way. Like so many users who started Unix computing in the 80’s, I started with the command line (for myself ksh and later bash), studiously internalizing command line tools and their arcane syntaxes to support file management, running programs, and systems administration. Overwhelmingly though, it was file management and running programs that I did through the command line.

For file management these days, Dired is my interface of choice. It is simply the more elegant tool for the job.

Case in point: renaming a bunch of files in a directory to arbitrary names. With a shell, my standard approach would have been to run some variant of ls -1 > foo.sh, edit foo.sh to insert mv on each line to a renamed target file, chmod u+x foo.sh to be executable, run foo.sh, delete foo.sh and call it a day.

With Dired, the above steps are replaced as such: make the buffer writable (via Wdired). Change the target filenames to a desired result, then commit the changes. This is even easier if there is a pattern you can use a regexp for. Unsurprisingly, all the basic file management operations that you would want are supported by Dired. Add Casual Dired to help make these operations discoverable and you’ll soon consider how quaint using mv, cp, rm, and ls are.

Running a simple command on a file? Again, you can do that with Dired. Move the point to the Dired line containing the file. Type “!” and enter a command in the prompt. You can optionally reference the filename in the command with the “?” character if you want to redirect its output to a file (e.g. cmd ? > outfile).

Taking file management and running simple commands out of what you would use a shell for, what’s left over? Source code management (SCM)?

Like for many others, git is my goto tool for SCM. Much has been said about the terrible user experience of the git command line and for years I suffered with its design decisions. Thankfully for Emacs users, there is Magit and VC mode which both provide a saner experience for it.

Running a Makefile? Use Emacs compile, which provides command completion for the targets defined in the Makefile and error/warning navigation if needed. (Try out Casual Make for editing Makefiles in Emacs.)

Do you need to run a command with arcane arguments repeatedly? Again, Makefile + compile to the rescue where it can be used as a task runner for that command.

Need robust terminal emulation? Eshell will fail you here and you are likely better off using a dedicated terminal emulator app, separate from Emacs. That said, I’ve found the built-in term to be good enough for many curses-style utilities.

Mining data files with piped commands? Eshell is a power tool here: used wrongly and you could figuratively cut off a limb. But used cleverly, Eshell offers great value. More on this later.

So with all these use cases described, why even use Eshell?

Using Eshell becomes a win only if you know Elisp. With that, you can think of Eshell as an Elisp REPL that can secondarily act as a shell.

Let’s not mince words. For many users this is a high bar, as it takes into account a lot of prerequisite knowledge. That said, learning basic Elisp is trivial for readers already conversant with programming and manageable for those that aren’t. Personally, I was very late (decades!) in taking the time to learn Elisp because I didn’t see the reward in it and so, prioritized accordingly. That hesitancy turned out to be unfounded. Elisp is easy to learn and the reward (or punishment) for knowing it is having the ability to really use the full capabilities of Emacs. (Know Python? Here’s a cheatsheat for Elisp that I wrote, hop in, the water’s fine…)

Once gained, bringing Elisp knowledge to using Eshell gives you a command line super power: the ability to improvise shell commands with Elisp functions.

Consider the following Eshell example where we wish to apply a command on a set of png files in a directory. Let’s start with a simple example that simply echoes filenames with suffix .png.

$ for i in *.png { echo $i }

In Eshell, you can replace echo $i with an Elisp expression.

$ for i in *.png { (format "%s" i) }

You can also mix shell commands and Elisp via dollar ($) expansion. Note that $ expansion in Eshell is different from other shells. A deeper reading is on it is recommended to avoid confusion with what works in conventional shells.

$ for i in *.png { echo $(format "%s" i) }

If you have ImageMagick, installed, you can use the convert utility to change this to a jpeg file, using the Elisp file name components functions to do the work of getting a desired target name.

$ for i in *.png { convert $i $(file-name-with-extension i "jpg") }

Contrast this with the equivalent expression in Bash which I consider to have much more forgettable syntax.

$ for i in *.png; do convert $i ${i/.png/.jpg}; done

Another significance with mixing shell commands and Elisp together is the ability to incorporate Emacs buffers into an improvised workflow. Shell commands are typically designed to work with data organized as files. In contrast, Elisp (rather, Emacs) treats files as a persisted, secondary form of data. Instead, Buffers are the primary data type in Emacs.

Recall the Dired naming example above? Consider the added steps due to using a temporary file foo.sh compared to using a writeable Dired buffer.

Eshell shifts you into thinking differently about working with a prompt, where instead of thinking of output being only a file or (stdout, stderr), the output could also be an Emacs buffer.

With that change in thinking, Eshell is better thought of as a “prompt” interface for Emacs which in turn serves as the interface to all the command line utilities made available to it. In this light, a whole swath of common shell workflows get replaced by Emacs.

Workflow	Shell	Eshell
File management	Orchestrate `cd`, `ls`, `cp`, `rm`, `mv`	Run `dired {optional path}`
View a file	Run `more` or `less`	Run `view-file`
SCM with git	Run `git` command(s)	Run `magit {optional path}`

Suffice to say, Eshell reinforces and rewards keeping Emacs users only in Emacs.

Another common shell workflow is using grep with pipes (|) for data mining files. For example:

$ grep {pat1} {file} | grep -v {pat2} | grep {pat3} >outfile

Using this pattern indiscriminately in Eshell is a recipe for unpleasant surprise if the file to be mined is large. This is because Eshell will ingest said file into Emacs as part of the pipeline processing. This will be slow. To avoid this, you can prefix each | with an * as follows:

$ grep {pat1} {file} *| grep -v {pat2} *| grep {pat3} >outfile

Why store a result in a file (outfile) that you have to open to see it and may not care to keep around? Here Eshell gives you the ability to redirect to a buffer.

$ grep {pat1} {file} *| grep -v {pat2} *| grep {pat3} >#<buffer "*my grep results*">

Note that Eshell supports creating/overwriting (>) and appending (>>) for redirection. Use > with care when working with an existing buffer.

What about piping shell command output to an Elisp function? At the time of this writing, you really can’t though according to this Reddit thread, this may change in the future.

If you are used to workflows that bleed out megabytes of data to stdout, you really shouldn’t use Eshell. But with some cleverness, Eshell can help you get insights to your data faster by leveraging all the tools Emacs can offer for this (occur, highlighting, grep, etc.).

Closing Thoughts

IMHO, Eshell is best thought primarily as a prompt for Elisp/Emacs functionality with the secondary benefit of running command line utilities with a “shell-like” experience. It should not be thought of as a “drop-in” replacement for an actual terminal shell. If full terminal emulation is desired, my guidance is to run a dedicated terminal emulator outside of Emacs.

To get the full benefit of using Eshell, you really need to be conversant with Elisp. That said, Eshell is actually a great way to start learning Elisp as it provides you a prompt interface (REPL) in much the same way that other languages like Python, JavaScript, Ruby, Java, Swift, etc do.1 Especially if you are comfortable with programming, take a day to learn Elisp. You won’t regret it.

Bringing Eshell into my Emacs journey has been amazing and I’m happy to have given it a second take.

Thanks to all the contributors of Eshell.

Footnotes

1 To clarify, these languages adopted the idea of a REPL from Lisp development which Elisp is descended from.

emacs

Discussion (9 comments)

ndegruchy•24 days ago

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.

imiric•25 days ago

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.

networked•24 days ago

> For file management these days, Dired is my interface of choice. It is simply the more elegant tool for the job. Case in point: renaming a bunch of files in a directory to arbitrary names. With a shell, my standard approach would have been to run some variant of `ls -1 > foo.sh`, edit `foo.sh` to insert `mv` on each line to a renamed target file, `chmod u+x foo.sh` to be executable, run `foo.sh`, delete `foo.sh` and call it a day.

I used to do this before I discovered vidir. [1] vidir is not actually tied to vi; it lets you rename and delete files through your `$EDITOR`. You edit a temporary file that looks like this:

  ...
  0093<tab>./fstab
  0094<tab>./fuse.conf
  0095<tab>./fwupd
  ...

There is also https://github.com/bulletmark/edir designed to improve on vidir. I haven't used it yet.

I'll give Emacs another try some day, I swear, and Dired is one of the reasons.

Edit: [1] I linked to https://github.com/trapd00r/vidir here at first. That is a fork; vidir comes from https://joeyh.name/code/moreutils/. You probably want the original. It is packaged for Debian, FreeBSD, Homebrew, etc. as part of the package `moreutils`.

cmrdporcupine•24 days ago

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.

Loading replies...

triclops200•24 days ago

I like the point raised by the author here about the power of elisp in the shell. For context, I've used emacs for well over a decade and write a good bit of elisp most weeks. However, I ended up finding elisp to be the wrong language for replacing a shell: it removes a lot of simplicity/convention for not enough reward, imo: it's just the wrong abstraction because elisp's most natural transformations are very stateful and buffer based, and, additionally, it really doesn't provide that much expanded capability in the end (and this is despite the fact that I'm one of those people who would absolutely never leave my emacs environment even for web browsing if I could feasibly make it work consistently for the kinds of things I need).

However, despite disliking python, I found https://xon.sh/ to be really excellent and provides a lot of the benefits of eshell, but better, in my humble opinion: it has a well-enough structured base language that is essentially already built to be a library glue-code language, which works really well with the unix philosophy that traditional shells utilize (a good library is just a tool that does a thing really well). It's really nice to just do things like this example

    from somelib import process_image #returns a file name that it saved to
    for f in $(some_executable_that_prints_a_file_list).strip().split("\n"):
      img = cv2.imread(f)
      cp @(process_image(img)) publish_dir
      make publish

It feels a lot like an extension of old shells to me rather than a complete replacement.

unixhero•24 days ago

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.

xenodium•24 days ago

Eshell clicked for me when I started treating it like most other Emacs modes, thus enabling my existing/favorite utils. The lines between shell and editor start to blur: https://xenodium.com/yasnippet-in-emacs-eshell

log101•25 days ago

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.

augustfengd•23 days ago

I've been using Dired for years and I've not heard of Wdired mode until now. This looks awesome.

Loading replies...