Subject: bug#79079: 31.0.50; Piped command output is sometimes lost in Eshell

From: Eli Zaretskii <[email-masked]>
Date: Sat, 16 Aug 2025 22:21:56 +0300

> Date: Sat, 16 Aug 2025 10:19:21 -0700
> Cc: [email-masked], [email-masked], [email-masked]
> From: Jim Porter <[email-masked]>
> 
> On 8/15/2025 11:04 PM, Eli Zaretskii wrote:
> >> +(defun process-tests/broken-pipe (connection-type)
> >> +  "Test handling of broken pipes; see bug#79079.
> >> +This test runs a shell script that reads a line of text and closes
> >> +stdin.  We send two lines of text to the script; the second should
> >> +signal an error indicating that the pipe has been closed.  The script
> >> +should also run to completion, printing out the line of text it read."
> >> +  (with-temp-buffer
> >> +    (let ((saw-error nil)
> >> +          (proc (make-process
> >> +                 :name "test" :buffer (current-buffer)
> >> +                 :command '("sh" "-c"
> >> +                            "read line; exec 0<&-; sleep 1; echo $line")
> > 
> > This will not work on Windows.  Can you come up with a test which
> > doesn't use features specific Posix shells?  E.g., can you perhaps use
> > Emacs itself as the other end of the pipe, running some special Lisp
> > program?
> 
> I thought that building Emacs on Windows used MSYS2, which provides a 
> Posix shell implementation. Am I just mistaken here?

Building, yes.  But this is a test suite, not a build script.

> It doesn't look like Emacs has the ability to close a file descriptor 
> from Lisp. I could add a C function to do this from Lisp, but I don't 
> know if it would be useful outside of this one test.

There's nothing wrong in having a function for the benefit of running
tests.  If suitably documented, it's okay, I think.

> Another alternative would be to write a small C program to call for this 
> test. That's probably straightforward if I can figure out the right 
> place to insert the necessary Makefile logic...

That would need a C compiler to run the test suite, something that is
much less desirable.

> >> +  (ert-deftest process-tests/broken-pipe/pty ()
> >> +    (process-tests/broken-pipe 'pty))
> >> +
> >> +  (ert-deftest process-tests/broken-pipe/pipe-stdin ()
> >> +    (process-tests/broken-pipe '(pipe . pty)))
> >> +
> >> +  (ert-deftest process-tests/broken-pipe/pty-stdin ()
> >> +    (process-tests/broken-pipe '(pty . pipe))))
> >> +
> > 
> > The PTY tests should be skipped on Windows, since PTYs aren't
> > supported there.
> 
> The tests aren't especially useful on Windows, but they should pass 
> (assuming the pipe test does), since on Windows we always use a pipe, 
> even if the user requests a PTY.

What would be the purpose of running the same tests several times?

> Covering these cases would catch any 
> bugs related to that, and would also mean we don't need to adjust these 
> later if we one day can support PTYs on Windows (I know this is really 
> up to Microsoft fixing their bugs though).

When we have a decent PTY support on Windows, this test will be the
least of our problems, given how much stuff will need to change.