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

[Jim Porter <jporterbugs@gmail.com>]

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

>>    *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'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.