Time for an EMACS shell-mode upgrade

[Glew, Andy]

(This started out addressed to an internal EMACS
user list, but I thought it might usefully be sent
to the broader world. Sorry about the Intel Inside
references.)


BRIEF
=====

It's time for me to upgrade my EMACS shell mode.

Standard EMACS 20.* and 21.* comint based 
shell.el doesn't handle cdpaths well.  In fact, 
that's why I have not upgraded in 15 years.

Does anyone have a shell mode that dynamically
tracks arbitrary change directories, with the shell
commands emitting the new directory and an EMACS
process filter recognizing the change?

Or: I just noticed eshell, the EMACS shell, in the
new EMACS 21* CVS web pages.  Has anyone
in DPG tried it?  

Related: is it possible to send CVS pserver across
the firewall?


DETAIL
======

I have, for the last 15 years, used a modification of one
of the original GNU EMACS shell.el shell-mode packages.
Its main advantage was that it tracked directory changes
much better than standard shell.el.  All of my directory
changing commands would print the new directory; 
my shell mode would recognize the new directory when it printed.

This works *much* better than standard shell.el,
which contains the comment attached at the bottom of this mail.
Basically, standard shell.el's directory tracking sucks.
In particular, it can't handle cdpath. I *depend* on cdpath.

Because of this, I haven't upgraded shell.el in 15 years.
However, bitrot has attacked my shell.el; features like
command history, etc., have broken as EMACS has changed,
while good features have been added to standard shell.el.

I would like to upgrade.  Hence my questions.

In particular, the comments in the standard shell.el say

;;; One good hack not implemented here for users of programmable shells
;;; is to program up the shell w.d. manipulation commands to output
;;; a coded command sequence to the tty. Something like
;;;     ESC | <cwd> |
;;; where <cwd> is the new current working directory. Then trash the
;;; directory tracking machinery currently used in this package, and
;;; replace it with a process filter that watches for and strips out
;;; these messages.

This is basically the technique that has served me well for 15 years.

Q: is anyone aware of extensions to the standard shell.el that do this?
I can write my own, but I'd rather find one already written.


Alternatively: I just noticed eshell.el, the shell written inside EMACS,
on the EMACS 21* CVS/web site. This looks good - the *right* *thing*
*to* *do*. Although eshell.el does not have cdpath now,
I'd gladly write it.

Q: has anyone reading this far used eshell?  How good is it?

Q: does eshell run on the old version of EMACS, 20.7, which is
in Intel's standard distribution /usr/intel/00r1?
        Is it an older version of eshell.el, or the latest?

Q: has anyone installed EMACS 21 at Intel? How hard was it? 
{I'm more concerned about whatever I do not being available
on every machine I access.}

Q: is it possible to use CVS pserver to access the http://savannah.gnu.org
CVS site? How does one get pserver tunnelled across the corporate
firewall?

Basically, I am trying to decide if I should
(a) modify standard shell.el to do cdpath etc the way I like
(b) write the process filter suggested by shell.el
(c) Ideally, find one of the above already written
(d) install eshell in the EMACS 20.7 we already have at work
(e) install my own EMACS 21 with eshell aleady in it
(f) write eshell cdpath...
?

I am trying to guess which will be the least waste of time.

====


Here are the comments from shell.el alluded to above:




;;; Directory tracking
;;;
;;; This code provides the shell mode input sentinel
;;;     SHELL-DIRECTORY-TRACKER
;;; that tracks cd, pushd, and popd commands issued to the shell, and
;;; changes the current directory of the shell buffer accordingly.
;;;
;;; This is basically a fragile hack, although it's more accurate than
;;; the version in Emacs 18's shell.el. It has the following failings:
;;; 1. It doesn't know about the cdpath shell variable.
;;; 2. It cannot infallibly deal with command sequences, though it does well
;;;    with these and with ignoring commands forked in another shell with
()s.
;;; 3. More generally, any complex command is going to throw it. Otherwise,
;;;    you'd have to build an entire shell interpreter in emacs lisp.
Failing
;;;    that, there's no way to catch shell commands where cd's are buried
;;;    inside conditional expressions, aliases, and so forth.
;;;
;;; The whole approach is a crock. Shell aliases mess it up. File sourcing
;;; messes it up. You run other processes under the shell; these each have
;;; separate working directories, and some have commands for manipulating
;;; their w.d.'s (e.g., the lcd command in ftp). Some of these programs have
;;; commands that do *not* affect the current w.d. at all, but look like
they
;;; do (e.g., the cd command in ftp).  In shells that allow you job
;;; control, you can switch between jobs, all having different w.d.'s. So
;;; simply saying %3 can shift your w.d..
;;;
;;; The solution is to relax, not stress out about it, and settle for
;;; a hack that works pretty well in typical circumstances. Remember
;;; that a half-assed solution is more in keeping with the spirit of Unix,
;;; anyway. Blech.
;;;
;;; One good hack not implemented here for users of programmable shells
;;; is to program up the shell w.d. manipulation commands to output
;;; a coded command sequence to the tty. Something like
;;;     ESC | <cwd> |
;;; where <cwd> is the new current working directory. Then trash the
;;; directory tracking machinery currently used in this package, and
;;; replace it with a process filter that watches for and strips out
;;; these messages.