That would be welcome.

And you've guessed wrong about my wanting to switch to eshell.el: I took a fairly long look at eshell.el, but adopted shell.el instead. After about 5 years of using shell.el, I wrote my own mode for running and capturing the output of command lines, which I have been happily using for the last 9 months.

Like shell.el, my mode relies on a traditional shell like bash or rc to parse the command lines entered into it.

Although I do want to learn how to use Emacs Lisp code to parse the command lines I write, when I do, I'll probably just turn most of those parse trees right back into command lines (i.e., strings) and pass them to rc, bash or dash.

Once I have the ability to quickly modify my Emacs to intercept the occasional command line before it is passed to a traditional shell, in other words, I will probably feel like I have all the control I need over my relationship with the somewhat unruly beast that is the traditional Unix shell and will not feel the need or desire for the code I wrote to actually stop sending command lines to it. I'm not one for making larger changes to my software environment than necessary.

If I could figure out which of the over 13,600 lines of code that is eshell.el is responsible for parsing command lines, I'd use that, but my experience with eshell.el leads me to believe that it will probably be quicker and easier for me just to write code from scratch.