On 7/26/2025 10:23 AM, Jim Porter wrote: > On 7/26/2025 3:15 AM, Eli Zaretskii wrote: >>> Date: Thu, 24 Jul 2025 08:52:16 -0700 >>> Cc: mail@daniel-mendler.de, 79079@debbugs.gnu.org >>> From: Jim Porter >>> >> So calling the filter of the "head"s process when we get EPIPE should >> fix that, no? > > It would probably fix this particular case, but I'm not sure it's the > correct way to do it in general. I'll construct some test programs to > test out some of the corner cases here so that we can be sure whatever > implementation we do settle on works correctly in all cases. After examining this more closely, there are three problems with the current Emacs code, of varying importance: 1. When we receive an EPIPE, we don't call our process-filter one last time (this is the original bug report). You can see this by running the following Eshell command repeatedly until it produces no output: git log | head -n 10 | cat 2. When we receive an EPIPE, we set the exit status to 256; that's not right, since the exit status should be 0. You can see this by running the following Eshell command until the prompt shows a non-zero status: git log | head -n 10 > # 3. If the child process closes stdin and wants to keep doing some work (like write to stdout), it can't, since we called 'deactivate_process'. You can see this with the attached script by running (it's supposed to print the first line of "git log"): git log | ./test-script.sh I've also attached two WIP patches for the different implementations. "bad-call-filter.diff" uses 'read_process_output' to call our process filter. It only solves issue #1 above. "good-close-pipe.diff" (which I posted previously) solves all three issues. While the latter is a slightly bigger change and requires some more testing on my end to make sure I've covered 100% of the cases, I think it's the more-correct solution. If we make the bigger change, it's probably worth calling it out in NEWS and on emacs-devel so that people can be on the lookout for any edge cases I haven't identified.