|
From: | Jim Porter |
Subject: | bug#54136: 29.0.50; Eshell emits extra prompts when killing processes in some cases |
Date: | Thu, 24 Feb 2022 10:55:48 -0800 |
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).
[Prev in Thread] | Current Thread | [Next in Thread] |