eshell

Homepage: https://www.gnu.org/software/emacs

Author: John Wiegley

Summary

The Emacs command shell

Commentary

_* What does Eshell offer you?

Despite the sheer fact that running an Emacs shell can be fun, here
are a few of the unique features offered by Eshell:

@ Integration with the Emacs Lisp programming environment

@ A high degree of configurability

@ The ability to have the same shell on every system Emacs has been
  ported to.  Since Eshell imposes no external requirements, and
  relies upon only the Lisp functions exposed by Emacs, it is quite
  operating system independent.  Several of the common UNIX
  commands, such as ls, mv, rm, ln, etc., have been implemented in
  Lisp in order to provide a more consistent work environment.

For those who might be using an older version of Eshell, version
2.1 represents an entirely new, module-based architecture.  It
supports most of the features offered by modern shells.  Here is a
brief list of some of its more visible features:

@ Command argument completion (tcsh, zsh)
@ Input history management (bash)
@ Intelligent output scrolling
@ Pseudo-devices (such as "/dev/clip" for copying to the clipboard)
@ Extended globbing (zsh)
@ Argument and globbing predication (zsh)
@ I/O redirection to buffers, files, symbols, processes, etc.
@ Many niceties otherwise seen only in 4DOS
@ Alias functions, both Lisp and Eshell-syntax
@ Piping, sequenced commands, background jobs, etc...

_* How to begin

To start using Eshell, simply type `M-x eshell'.

_* Philosophy

A shell is a layer which metaphorically surrounds the kernel, or
heart of an operating system.  This kernel can be seen as an engine
of pure functionality, waiting to serve, while the user programs
take advantage of that functionality to accomplish their purpose.

The shell's role is to make that functionality accessible to the
user in an unformed state.  Very roughly, it associates kernel
functionality with textual commands, allowing the user to interact
with the operating system via linguistic constructs.  Process
invocation is perhaps the most significant form this takes, using
the kernel's `fork' and `exec' functions.

Other programs also interact with the functionality of the kernel,
but these user applications typically offer a specific range of
functionality, and thus are not classed as "shells" proper.
(What they lose in quiddity, they gain in rigidity).

Emacs is also a user application, but it does make the
functionality of the kernel accessible through an interpreted
language -- namely, Lisp.  For that reason, there is little
preventing Emacs from serving the same role as a modern shell.  It
too can manipulate the kernel in an unpredetermined way to cause
system changes.  All it's missing is the shell-ish linguistic
model.

Enter Eshell.  Eshell translates "shell-like" syntax into Lisp
in order to exercise the kernel in the same manner as typical
system shells.  There is a fundamental difference here, however,
although it may seem subtle at first...

Shells like csh and Bourne shell were written several decades ago,
in different times, under more restrictive circumstances.  This
confined perspective shows itself in the paradigm used by nearly
all command-line shells since.  They are linear in conception, byte
stream-based, sequential, and confined to movement within a single
host machine.

Emacs, on the other hand, is more than just a limited translator
that can invoke subprocesses and redirect file handles.  It also
manages character buffers, windowing frames, network connections,
registers, bookmarks, processes, etc.  In other words, it's a very
multi-dimensional environment, within which eshell emulates a highly
linear methodology.

Taking a moment, let's look at how this could affect the future of
a shell allowed to develop in such a wider field of play:

@ There is no reason why directory movement should be linear, and
  confined to a single file-system.  Emacs, through w3 and ange-ftp,
  has access to the entire Web.  Why not allow a user to cd to
  multiple directories simultaneously, for example?  It might make
  some tasks easier, such as diff'ing files separated by very long
  pathnames.

@ Data sources are available from anywhere Emacs can derive
  information from: not just from files or the output of other
  processes.

@ Multiple shell invocations all share the same environment -- even
  the same process list!  It would be possible to have "process
  views", so that one buffer is watching standard output, another
  standard error, and another the result of standard output grep'd
  through a regular expression...

@ It is not necessary to "leave" the shell, losing all input and
  output history, environment variables, directory stack, etc.
  Emacs could save the contents of your eshell environment, and
  restore all of it (or at least as much as possible) each time you
  restart.  This could occur automatically, without requiring
  complex initialization scripts.

@ Typos occur all of the time; many of them are repeats of common
  errors, such as 'dri' for `dir'.  Since executing non-existent
  programs is rarely the intention of the user, eshell could prompt
  for the replacement string, and then record that in a database of
  known misspellings.  (Note: The typo at the beginning of this
  paragraph wasn't discovered until two months after I wrote the
  text; it was not intentional).

@ Emacs's register and bookmarking facilities can be used for
  remembering where you've been, and what you've seen -- to varying
  levels of persistence.  They could perhaps even be tied to
  specific "moments" during eshell execution, which would include
  the environment at that time, as well as other variables.
  Although this would require functionality orthogonal to Emacs's
  own bookmarking facilities, the interface used could be made to
  operate very similarly.

This presents a brief idea of what the fuller dimensionality of an
Emacs shell could offer.  It's not just the language of a shell
that determines how it's used, but also the Weltanschauung
underlying its design -- and which is felt behind even the smallest
feature.  I would hope the freedom provided by using Emacs as a
parent environment will invite rich ideas from others.  It
certainly feels as though all I've done so far is to tie down the
horse, so to speak, so that he will run at a man's pace.

_* Influences

The author of Eshell has been a long-time user of the following
shells, all of which contributed to Eshell's design:

@ rc
@ bash
@ zsh
@ sh
@ 4nt
@ csh

Dependencies

Reverse dependencies