GNU bug report logs - #79079
31.0.50; Piped command output is sometimes lost in Eshell

Previous Next

Full log

Message #125 received at 79079 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: mail <at> daniel-mendler.de, eggert <at> cs.ucla.edu, 79079 <at> debbugs.gnu.org
Subject: Re: bug#79079: 31.0.50; Piped command output is sometimes lost in
 Eshell
Date: Sat, 16 Aug 2025 22:21:56 +0300

> Date: Sat, 16 Aug 2025 10:19:21 -0700
> Cc: mail <at> daniel-mendler.de, eggert <at> cs.ucla.edu, 79079 <at> debbugs.gnu.org
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.