GNU bug report logs -
#56025
29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
Previous Next
Reported by: Ken Brown <kbrown <at> cornell.edu>
Date: Thu, 16 Jun 2022 18:36:02 UTC
Severity: normal
Found in version 29.0.50
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #142 received at 56025 <at> debbugs.gnu.org (full text, mbox):
On 7/16/2022 10:35 PM, Jim Porter wrote:
> Ok, attached is a WIP patch to do this. It seems to work for me under Cygwin,
> although I've only lightly tested it in that environment. If this works for you
> too, I'll finish cleaning this up and add tests/documentation for it.
It does work for me too. Thanks!
> Note that in my patch, I temporarily undid my previous patch to send EOF
> multiple times. This is just for testing purposes, but since we're using a pipe
> for this connection now, a single call to `process-send-eof' should be
> sufficient.
There shouldn't be a need for any calls to process-send-eof. This is a noop
anyway when writing to a pipe, as it should be. A process reading from a pipe
automatically recognizes EOF when a read returns 0 bytes, which is supposed to
happen when no process has the pipe open for writing.
> (There are some obscure cases where we might want to keep the
> current behavior, like redirecting to a process created some other way, so I
> think it makes sense to keep that code. Probably...)
Ideally, Eshell should know whether it's writing to a pipe or a pty. It should
send up to 3 EOFs in the latter case and 0 in the former case. If it's too hard
to arrange that, then it's probably harmless to send up to 3 EOFs in the pipe
case too. But then maybe a comment in the code would be useful, so that readers
don't wonder why you're sending EOF to a pipe.
Thanks again for your work.
Ken
This bug report was last modified 2 years and 350 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.