GNU bug report logs - #56025
29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin

Previous Next

Full log

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

From: Jim Porter <jporterbugs <at> gmail.com>
To: Sean Whitton <spwhitton <at> email.arizona.edu>, Eli Zaretskii <eliz <at> gnu.org>, 
 Ken Brown <kbrown <at> cornell.edu>
Cc: larsi <at> gnus.org, 56025 <at> debbugs.gnu.org
Subject: Re: bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
Date: Fri, 24 Jun 2022 16:03:13 -0700

On 6/24/2022 3:23 PM, Sean Whitton wrote:
> On Fri 24 Jun 2022 at 09:53AM -07, Jim Porter wrote:
> 
>> How about the attached patch? I didn't check for specific platforms to
>> enable the "third EOF" behavior, since a) it's hard to say for sure
>> which platforms might have this issue (especially since Cygwin will be
>> fixing it), and b) this lets us avoid worrying about Tramp compatibility.
> 
> Avoiding the TRAMP issues makes sense, but could you explain why you
> don't think there could be an issue with sending a process too many
> EOFs?  It's not immediately obvious to me.

Eshell was already sending too many EOFs in some cases, and we haven't 
seen any issues with it (that I know of). For example, consider the command:

  *echo hi | rev

In this case, we send the string "hi\n" over the pipe, followed by 2 
EOFs (one from the stdout handle and one from the stderr handle). The 
POSIX standard says[1] (thanks to Eliot Moss on the Cygwin mailing list 
for citing this passage):

  When [EOF is] received, all the bytes waiting to be read are
  immediately passed to the process without waiting for a <newline>, and
  the EOF is discarded. Thus, if there are no bytes waiting (that is,
  the EOF occurred at the beginning of a line), a byte count of zero
  shall be returned from the read(), representing an end-of-file
  indication.

I interpret that to mean that the preferred way to indicate end-of-file 
to `rev' in this case is to send it "hi [NL] [EOF]". The second EOF that 
Eshell sends when closing the stderr output handle is superfluous, but 
it works fine as far as I can tell.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap11.html

Previous Next

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