bug#54136: 29.0.50; Eshell emits extra prompts when killing processes in some cases

[Jim Porter <jporterbugs@gmail.com>]

On 2/24/2022 3:03 AM, Eli Zaretskii wrote:
>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Thu, 24 Feb 2022 10:35:32 +0100
>> Cc: 54136@debbugs.gnu.org
>>
>> Thanks; pushed to Emacs 29.
> 
> The new tests fail on MS-Windows.  Does the patch below look right?

Thanks, and sorry for the breakage.

> I'm quite sure about the "sh" vs "sh.exe" part, but what about the
> "killed" vs "interrupt" part? any idea why this happens on MS-Windows?

I think this makes sense. POSIX-style signal handling on MS Windows is 
only approximate, so I'm not surprised it produces some surprising 
results like that. Maybe it's possible to pass the signal code through 
the process exit status more accurately, but that's probably only a 
partial solution at best (due to the API differences), and at worst 
could break Emacs's subprocess handling for MS Windows in subtle ways.

Another solution would be to replace the call to `eshell-kill-process' 
in `esh-proc-test/kill-pipeline' with `eshell-interrupt-process'. Then 
the exit status should be "interrupt\n" on all platforms. I've verified 
that that works ok on GNU/Linux, but it's possible that it runs into 
some other issue on MS Windows.

This is sort of just working around the issue, but I also think there's 
an argument that `eshell-interrupt-process' is the more "natural" 
function to call, since it corresponds to a user hitting ^C in the shell 
(or C-c C-c in Eshell).