On 6/23/2022 9:40 PM, Sean Whitton wrote:
 > I'm a bit queasy about an unbounded loop here.  Why not just try three
 > times?  Or, better, try twice, and a third time only if we're on a
 > platform where we know it's needed.

How about the attached patch? I didn't check for specific platforms to 
enable the "third EOF" behavior, since a) it's hard to say for sure 
which platforms might have this issue (especially since Cygwin will be 
fixing it), and b) this lets us avoid worrying about Tramp compatibility.

 > Many thanks for the investigative work.

Agreed, this turned out to be a much subtler problem than I had 
initially suspected. Thanks!

On 6/23/2022 11:07 PM, Eli Zaretskii wrote:
> Please add there comments explaining why this is done, or at least
> point to relevant messages in this bug's discussion (NOT just to the
> bug number, as the discussion is long and it will be hard to
> understand what part of it is relevant).  Such "tricky" code should
> always have comments explaining it.

I added a comment explaining this to the best of my knowledge. There's 
one additional caveat I didn't mention there though, since it's only 
somewhat related. I believe this was mentioned earlier in the thread, 
but when Eshell creates a pipe, it routes both stdout and stderr to the 
next process's stdin (there's no way to control this behavior yet). When 
closing the handles from the initial process, it then calls 
`eshell-close-target' twice: once for stdout and once for stderr. Thus, 
with this patch, we'll call `process-send-eof' up to six times.

I'm not sure this is really a problem in practice today, but it might 
come up if Eshell gains the ability to redirect stdout and stderr 
separately.