Subject: bug#59469: Adding a simpler duplication of the issue

From: Jim Porter <[email-masked]>
Date: Mon, 21 Nov 2022 20:56:16 -0800

On 11/21/2022 6:50 PM, Milan Zimmermann wrote:
> A simpler duplication shows the issue is below.
[snip]
> Same bug: After the call to non-elisp program, /usr/bin/gzip, a 
> previously exported variable bbb (exported inside the block) is nullified.

I'm not entirely sure, but I have a suspicion that this is due to 
Eshell's deferred commands. Deferred commands tell Eshell to stop 
processing synchronously and yield to the rest of Emacs. It's a way of 
keeping long-running commands (e.g. external processes) from hanging the 
rest of Emacs.

Unfortunately, the logic to do this (see 'eshell-do-eval') was written 
before lexical binding was added to Emacs Lisp, and I think this is the 
cause of quite a few subtle bugs with Eshell command evaluation. Fixing 
that is bug#57635, which would leverage the generator.el internals to do 
this.

Of course, I could be wrong. This is reaching well past my comfort zone 
for Emacs Lisp, but this sure seems like an issue with 'eshell-do-eval'.

I'd certainly like to fix this one day, since it's blocking a few other 
things I want to do in Eshell, but I think it'll be a pretty big project.