Thanks for the detailed update as always.

This is over my elisp level, I got here mostly as a relapsed eshell user, trying to use eshell as my primary shell for the third time :)

But it sounds to me like your intuition about this could be fixed by rewriting the core 'eshell-do-eval' loop in bug#57635 can be correct.  I would enjoy helping with  it, but at the moment it is above my time and elisp abilities.

Not sure what to do next regarding this bug, perhaps we should go ahead and add your comment to   bug#57635 so these two are linked from both ends? Or let me know if I can help with something else,

Thanks,
Milan


On Mon, Nov 21, 2022 at 11:56 PM Jim Porter <jporterbugs@gmail.com> wrote:
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.