bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin

[Ken Brown]

On 6/18/2022 6:00 PM, Jim Porter wrote:
> On 6/18/2022 1:51 PM, Ken Brown wrote:
> > On 6/18/2022 3:02 PM, Jim Porter wrote:
> > > On 6/18/2022 10:52 AM, Ken Brown wrote:
> > > > No, I'm seeing the same results on Emacs 28.  On both Emacs 28 and Emacs 29, 
> > > > rev is apparently not seeing EOF unless echo outputs a newline, so rev keeps 
> > > > waiting for input.
> > > Ah ha! Thanks for debugging this. The minimal fix then would be to change the 
> > > command in em-extpipe-test-2 to either of these:
> > >    echo -N "bar" | rev *>temp
> > This doesn't work.  It still hangs when run interactively...
> Just to confirm, the above command hangs, but the following works, correct?
>
>    echo -N "bar" | rev
Correct.

> > >    *echo "bar" | rev *>temp
> > This works interactively...
> All this makes me think that we could be dealing with a race condition in how 
> Eshell pipes I/O around. Maybe there's a timing issue in `eshell-close-target' 
> where we end up not sending EOF to the "rev" (or "sh") process?
I think I've just discovered an anomaly in "rev" on Cygwin that could partially 
explain what I'm seeing.  I'll investigate that before proceeding further.
> I'd be interested to see the results if you ran `M-x trace-function' for 
> `eshell-close-target' and `process-status' before trying these commands. 
> `process-status' should return `run' when called from inside 
> `eshell-close-target'. If it doesn't, then we'd neglect to send EOF to "rev" (or 
> "sh"), which would cause a hang like what you're seeing.
> If that's not the issue, then I'm not sure what the issue would be exactly, but 
> poking around in `eshell-close-target', `eshell-insertion-filter', and 
> `eshell-sentinel' might yield some useful info.
> > My guess is that it's the latter, but I don't know if it's worth pursuing this 
> > if Cygwin and EMBA are the only platforms on which there's a problem.  Of 
> > course, there might be other platforms and no one has reported it.
> I think if we could figure out the real issue, it would be great to fix it. 
> Though if we can't, it would probably be ok to just fix the test by avoiding the 
> issue.