Attached is a patch for this with some regression tests (unfortunately, 
we can only run them in an interactive session, since Emacs will 
terminate itself in batch mode upon receiving a SIGPIPE). I've also 
called out the change in NEWS so that users are aware.

On 7/26/2025 2:12 PM, Jim Porter wrote:
> 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 > #<my-buffer>
> 
> 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.