unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
@ 2022-06-16 18:30 Ken Brown
  2022-06-16 19:30 ` Sean Whitton
  0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2022-06-16 18:30 UTC (permalink / raw)
  To: 56025; +Cc: Sean Whitton

In commit 231a1ba3, Lars disabled the extpipe tests on EMBA "because they 
apparently time out".  The EMBA log he cited in the commit message shows that 
only em-extpipe-test-2 times out.  And this same test (but no others) also times 
out on Cygwin:

$ make -C test em-extpipe-tests
[...]
Test em-extpipe-test-2 backtrace:
   signal(error ("timed out waiting for subprocess(es)"))
   error("timed out waiting for subprocess(es)")
   eshell-wait-for-subprocess()
   eshell-command-result-p("echo \"bar\" | rev *>/tmp/emacs-test-Rw5ILv
   (let ((input (replace-regexp-in-string "temp\\([^>]\\|\\'\\)" temp (
   (unwind-protect (let ((input (replace-regexp-in-string "temp\\([^>]\
   (let ((temp-buffer (generate-new-buffer " *temp*" t))) (unwind-prote
   (progn (let ((temp-buffer (generate-new-buffer " *temp*" t))) (unwin
   (unwind-protect (progn (let ((temp-buffer (generate-new-buffer " *te
   (let* ((coding-system-for-write nil) (temp-file (identity (make-temp
   (save-current-buffer (set-buffer eshell-buffer) (let* ((fn-38 #'exec
   (unwind-protect (save-current-buffer (set-buffer eshell-buffer) (let
   (let* ((process-environment (cons "HISTFILE" process-environment)) (
   (progn (let* ((process-environment (cons "HISTFILE" process-environm
   (unwind-protect (progn (let* ((process-environment (cons "HISTFILE"
   (let* ((coding-system-for-write nil) (temp-file (file-name-as-direct
   (save-current-buffer (let* ((coding-system-for-write nil) (temp-file
   (let ((input "echo \"bar\" | rev *>temp")) (save-current-buffer (let
   (progn (let ((value-24 (gensym "ert-form-evaluation-aborted-"))) (le
   (closure (t) nil (progn (let ((value-24 (gensym "ert-form-evaluation
   ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
   ert-run-test(#s(ert-test :name em-extpipe-test-2 :documentation nil
   ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
   ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil
   ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp))))
   ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco
   eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n
   command-line-1(("-L" ":../../master/test" "-l" "ert" "-l" "lisp/eshe
   command-line()
   normal-top-level()
Test em-extpipe-test-2 condition:
     (error "timed out waiting for subprocess(es)")
    FAILED  10/17  em-extpipe-test-2 (5.237846 sec) at 
../../master/test/lisp/eshell/em-extpipe-tests.el:87

I don't see what's special about this test that would cause it to time out on 
some systems.  Sean, do you have any ideas?  If not, I suggest just skipping it 
on Cygwin.  And maybe we should skip just this extpipe test (rather than all of 
them) on EMBA.

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-16 18:30 bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin Ken Brown
@ 2022-06-16 19:30 ` Sean Whitton
  2022-06-16 22:01   ` Ken Brown
  0 siblings, 1 reply; 36+ messages in thread
From: Sean Whitton @ 2022-06-16 19:30 UTC (permalink / raw)
  To: Ken Brown, 56025

Hello Ken,

On Thu 16 Jun 2022 at 02:30pm -04, Ken Brown wrote:

> In commit 231a1ba3, Lars disabled the extpipe tests on EMBA "because they
> apparently time out".  The EMBA log he cited in the commit message shows that
> only em-extpipe-test-2 times out.  And this same test (but no others) also times
> out on Cygwin:

That test invokes `sh -c "rev >temp"` as its only subprocess, so that's
probably what is timing out.  Is there something different about
Cygwin's sh?  Something about EOFs?

-- 
Sean Whitton





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-16 19:30 ` Sean Whitton
@ 2022-06-16 22:01   ` Ken Brown
  2022-06-17 13:39     ` Ken Brown
  0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2022-06-16 22:01 UTC (permalink / raw)
  To: Sean Whitton, 56025

On 6/16/2022 3:30 PM, Sean Whitton wrote:
> Hello Ken,
> 
> On Thu 16 Jun 2022 at 02:30pm -04, Ken Brown wrote:
> 
>> In commit 231a1ba3, Lars disabled the extpipe tests on EMBA "because they
>> apparently time out".  The EMBA log he cited in the commit message shows that
>> only em-extpipe-test-2 times out.  And this same test (but no others) also times
>> out on Cygwin:
> 
> That test invokes `sh -c "rev >temp"` as its only subprocess, so that's
> probably what is timing out.  Is there something different about
> Cygwin's sh?  Something about EOFs?

I'm not aware of anything different.  Here's what happens when I run the test 
interactively:

$ time echo \"bar\" | sh -c "rev >temp"

real    0m0.100s
user    0m0.030s
sys     0m0.030s

$ cat temp
"rab"

And keep in mind that the test also times out on EMBA.

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-16 22:01   ` Ken Brown
@ 2022-06-17 13:39     ` Ken Brown
  2022-06-18  0:57       ` Sean Whitton
  0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2022-06-17 13:39 UTC (permalink / raw)
  To: Sean Whitton, 56025, Lars Magne Ingebrigtsen

On 6/16/2022 6:01 PM, Ken Brown wrote:
> On 6/16/2022 3:30 PM, Sean Whitton wrote:
>> Hello Ken,
>>
>> On Thu 16 Jun 2022 at 02:30pm -04, Ken Brown wrote:
>>
>>> In commit 231a1ba3, Lars disabled the extpipe tests on EMBA "because they
>>> apparently time out".  The EMBA log he cited in the commit message shows that
>>> only em-extpipe-test-2 times out.  And this same test (but no others) also times
>>> out on Cygwin:
>>
>> That test invokes `sh -c "rev >temp"` as its only subprocess, so that's
>> probably what is timing out.  Is there something different about
>> Cygwin's sh?  Something about EOFs?
> 
> I'm not aware of anything different.  Here's what happens when I run the test 
> interactively:
> 
> $ time echo \"bar\" | sh -c "rev >temp"
> 
> real    0m0.100s
> user    0m0.030s
> sys     0m0.030s
> 
> $ cat temp
> "rab"
> 
> And keep in mind that the test also times out on EMBA.

I just tried a different experiment: In an interactive emacs-29 session, I 
started eshell and typed

   echo \"bar\" | rev *>temp

Nothing visible happens until I type 'C-c C-c'.  Then a prompt appears again, 
and 'ls -l' shows that temp exists and is empty.

Prior to typing 'C-c C-c', 'M-x list-processes' (or 'C-c C-s') shows a bash 
process running but it doesn't show 'rev'.  But running 'ps' outside of emacs 
shows both 'rev' and its parent 'bash' process.

It does seem that there's an actual bug here, not just a test that should be 
skipped because it times out.  It could be a Cygwin bug, of course, but that 
doesn't explain the EMBA failure.

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-17 13:39     ` Ken Brown
@ 2022-06-18  0:57       ` Sean Whitton
  2022-06-18  2:07         ` Ken Brown
  0 siblings, 1 reply; 36+ messages in thread
From: Sean Whitton @ 2022-06-18  0:57 UTC (permalink / raw)
  To: Ken Brown, 56025, Lars Magne Ingebrigtsen

Hello,

On Fri 17 Jun 2022 at 09:39am -04, Ken Brown wrote:

> On 6/16/2022 6:01 PM, Ken Brown wrote:
>> On 6/16/2022 3:30 PM, Sean Whitton wrote:
>>> Hello Ken,
>>>
>>> On Thu 16 Jun 2022 at 02:30pm -04, Ken Brown wrote:
>>>
>>>> In commit 231a1ba3, Lars disabled the extpipe tests on EMBA "because they
>>>> apparently time out".  The EMBA log he cited in the commit message shows that
>>>> only em-extpipe-test-2 times out.  And this same test (but no others) also times
>>>> out on Cygwin:
>>>
>>> That test invokes `sh -c "rev >temp"` as its only subprocess, so that's
>>> probably what is timing out.  Is there something different about
>>> Cygwin's sh?  Something about EOFs?
>>
>> I'm not aware of anything different.  Here's what happens when I run the test
>> interactively:
>>
>> $ time echo \"bar\" | sh -c "rev >temp"
>>
>> real    0m0.100s
>> user    0m0.030s
>> sys     0m0.030s
>>
>> $ cat temp
>> "rab"
>>
>> And keep in mind that the test also times out on EMBA.
>
> I just tried a different experiment: In an interactive emacs-29 session, I
> started eshell and typed
>
>    echo \"bar\" | rev *>temp
>
> Nothing visible happens until I type 'C-c C-c'.  Then a prompt appears again,
> and 'ls -l' shows that temp exists and is empty.
>
> Prior to typing 'C-c C-c', 'M-x list-processes' (or 'C-c C-s') shows a bash
> process running but it doesn't show 'rev'.  But running 'ps' outside of emacs
> shows both 'rev' and its parent 'bash' process.
>
> It does seem that there's an actual bug here, not just a test that should be
> skipped because it times out.  It could be a Cygwin bug, of course, but that
> doesn't explain the EMBA failure.

Could you see if the same thing happens if you type

    echo "bar" | sh -c "rev >temp"

into an interactive session, please?

If it's the same then extpipe has uncovered a general Eshell bug.

-- 
Sean Whitton





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-18  0:57       ` Sean Whitton
@ 2022-06-18  2:07         ` Ken Brown
  2022-06-18  2:35           ` Ken Brown
  2022-06-18  3:50           ` Jim Porter
  0 siblings, 2 replies; 36+ messages in thread
From: Ken Brown @ 2022-06-18  2:07 UTC (permalink / raw)
  To: Sean Whitton, 56025, Lars Magne Ingebrigtsen

On 6/17/2022 8:57 PM, Sean Whitton wrote:
> On Fri 17 Jun 2022 at 09:39am -04, Ken Brown wrote:
>> I just tried a different experiment: In an interactive emacs-29 session, I
>> started eshell and typed
>>
>>     echo \"bar\" | rev *>temp
>>
>> Nothing visible happens until I type 'C-c C-c'.  Then a prompt appears again,
>> and 'ls -l' shows that temp exists and is empty.
>>
>> Prior to typing 'C-c C-c', 'M-x list-processes' (or 'C-c C-s') shows a bash
>> process running but it doesn't show 'rev'.  But running 'ps' outside of emacs
>> shows both 'rev' and its parent 'bash' process.
>>
>> It does seem that there's an actual bug here, not just a test that should be
>> skipped because it times out.  It could be a Cygwin bug, of course, but that
>> doesn't explain the EMBA failure.
> 
> Could you see if the same thing happens if you type
> 
>      echo "bar" | sh -c "rev >temp"
> 
> into an interactive session, please?
> 
> If it's the same then extpipe has uncovered a general Eshell bug.

Yes, it's the same.  And it's even the same if I remove the quotation marks 
around "rev >temp".

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-18  2:07         ` Ken Brown
@ 2022-06-18  2:35           ` Ken Brown
  2022-06-18  3:50           ` Jim Porter
  1 sibling, 0 replies; 36+ messages in thread
From: Ken Brown @ 2022-06-18  2:35 UTC (permalink / raw)
  To: Sean Whitton, 56025, Lars Magne Ingebrigtsen

On 6/17/2022 10:07 PM, Ken Brown wrote:
> On 6/17/2022 8:57 PM, Sean Whitton wrote:
>> On Fri 17 Jun 2022 at 09:39am -04, Ken Brown wrote:
>>> I just tried a different experiment: In an interactive emacs-29 session, I
>>> started eshell and typed
>>>
>>>     echo \"bar\" | rev *>temp
>>>
>>> Nothing visible happens until I type 'C-c C-c'.  Then a prompt appears again,
>>> and 'ls -l' shows that temp exists and is empty.
>>>
>>> Prior to typing 'C-c C-c', 'M-x list-processes' (or 'C-c C-s') shows a bash
>>> process running but it doesn't show 'rev'.  But running 'ps' outside of emacs
>>> shows both 'rev' and its parent 'bash' process.
>>>
>>> It does seem that there's an actual bug here, not just a test that should be
>>> skipped because it times out.  It could be a Cygwin bug, of course, but that
>>> doesn't explain the EMBA failure.
>>
>> Could you see if the same thing happens if you type
>>
>>      echo "bar" | sh -c "rev >temp"
>>
>> into an interactive session, please?
>>
>> If it's the same then extpipe has uncovered a general Eshell bug.
> 
> Yes, it's the same.  And it's even the same if I remove the quotation marks 
> around "rev >temp".

And it's also the same if remove the output redirection, i.e., if I type 'echo 
bar | sh -c rev'.  On the other hand, if I type 'echo bar | rev', then I see the 
output 'rab'; but rev doesn't exit, and I don't get the eshell prompt, until I 
type 'C-c C-c'.  On the third hand, 'echo bar | cat' almost works; I see the 
output 'bar' followed immediately by the eshell prompt (with no newline after 
'bar').  Is eshell stripping newlines in some circumstances?  If so, I wonder if 
this accounts for the failure of rev to exit in some of the earlier examples, 
since it operates on lines?

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-18  2:07         ` Ken Brown
  2022-06-18  2:35           ` Ken Brown
@ 2022-06-18  3:50           ` Jim Porter
  2022-06-18 17:52             ` Ken Brown
  1 sibling, 1 reply; 36+ messages in thread
From: Jim Porter @ 2022-06-18  3:50 UTC (permalink / raw)
  To: Ken Brown, Sean Whitton, 56025, Lars Magne Ingebrigtsen

On 6/17/2022 7:07 PM, Ken Brown wrote:
> On 6/17/2022 8:57 PM, Sean Whitton wrote:
>> Could you see if the same thing happens if you type
>>
>>      echo "bar" | sh -c "rev >temp"
>>
>> into an interactive session, please?
>>
>> If it's the same then extpipe has uncovered a general Eshell bug.
> 
> Yes, it's the same.  And it's even the same if I remove the quotation 
> marks around "rev >temp".

Does the above command also fail on Emacs 28? I changed some aspects of 
process management for Eshell in Emacs 29, so it's possible this is a 
regression. If it works correctly under Emacs 28, I'd be very interested 
to see the results of bisecting to find the breaking commit.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-18  3:50           ` Jim Porter
@ 2022-06-18 17:52             ` Ken Brown
  2022-06-18 19:02               ` Jim Porter
  0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2022-06-18 17:52 UTC (permalink / raw)
  To: Jim Porter, Sean Whitton, 56025, Lars Magne Ingebrigtsen

On 6/17/2022 11:50 PM, Jim Porter wrote:
> On 6/17/2022 7:07 PM, Ken Brown wrote:
>> On 6/17/2022 8:57 PM, Sean Whitton wrote:
>>> Could you see if the same thing happens if you type
>>>
>>>      echo "bar" | sh -c "rev >temp"
>>>
>>> into an interactive session, please?
>>>
>>> If it's the same then extpipe has uncovered a general Eshell bug.
>>
>> Yes, it's the same.  And it's even the same if I remove the quotation marks 
>> around "rev >temp".
> 
> Does the above command also fail on Emacs 28? I changed some aspects of process 
> management for Eshell in Emacs 29, so it's possible this is a regression. If it 
> works correctly under Emacs 28, I'd be very interested to see the results of 
> bisecting to find the breaking commit.

No, I'm seeing the same results on Emacs 28.  On both Emacs 28 and Emacs 29, rev 
is apparently not seeing EOF unless echo outputs a newline, so rev keeps waiting 
for input.

[Side note: It took me a while to sort this out because (a) Eshell's echo does 
not output a newline by default, in contrast to Bash's builtin echo; (b) in 
Eshell in Emacs 28, you use '-n' to add a newline, while in Bash '-n' suppresses 
the newline; and (c) in Eshell in Emacs 29, you use '-N' to add a newline.]

Here's my simplest reproduction recipe for the bug: Type 'echo bar | rev' into 
Eshell.  In both Emacs 28 and Emacs 29, 'rab' is output but rev keeps running.

But if I make echo output a newline (by '-n' in Emacs 28 and '-N' in Emacs 29), 
then rev exits after outputting 'rab' (followed by newline).

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-18 17:52             ` Ken Brown
@ 2022-06-18 19:02               ` Jim Porter
  2022-06-18 20:51                 ` Ken Brown
  0 siblings, 1 reply; 36+ messages in thread
From: Jim Porter @ 2022-06-18 19:02 UTC (permalink / raw)
  To: Ken Brown, Sean Whitton, 56025, Lars Magne Ingebrigtsen

On 6/18/2022 10:52 AM, Ken Brown wrote:
> No, I'm seeing the same results on Emacs 28.  On both Emacs 28 and Emacs 
> 29, rev is apparently not seeing EOF unless echo outputs a newline, so 
> rev keeps waiting for input.

Ah ha! Thanks for debugging this. The minimal fix then would be to 
change the command in em-extpipe-test-2 to either of these:

   echo -N "bar" | rev *>temp
   *echo "bar" | rev *>temp

One last[1] question: if you ran "echo -n bar | rev" in Cygwin Bash, 
does it hang there too? Maybe this is just a Cygwin limitation, or maybe 
Eshell is doing something wrong with its built-in pipelines in this 
situation.

> [Side note: It took me a while to sort this out because (a) Eshell's 
> echo does not output a newline by default, in contrast to Bash's builtin 
> echo; (b) in Eshell in Emacs 28, you use '-n' to add a newline, while in 
> Bash '-n' suppresses the newline; and (c) in Eshell in Emacs 29, you use 
> '-N' to add a newline.]

This is one of the parts of Eshell that's always bothered me a bit. 
Eshell's echo is different enough from other echo implementations that 
it's easy to get tripped up. There's some further discussion of this in 
bug#12689 as well. I'm hesitant to change Eshell's echo too much, since 
it could break user scripts, but it would be nice if we could find a 
reasonably-compatible way of making it work more like /bin/echo.

[1] Well, probably last.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-18 19:02               ` Jim Porter
@ 2022-06-18 20:51                 ` Ken Brown
  2022-06-18 22:00                   ` Jim Porter
  0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2022-06-18 20:51 UTC (permalink / raw)
  To: Jim Porter, Sean Whitton, 56025, Lars Magne Ingebrigtsen

On 6/18/2022 3:02 PM, Jim Porter wrote:
> On 6/18/2022 10:52 AM, Ken Brown wrote:
>> No, I'm seeing the same results on Emacs 28.  On both Emacs 28 and Emacs 29, 
>> rev is apparently not seeing EOF unless echo outputs a newline, so rev keeps 
>> waiting for input.
> 
> Ah ha! Thanks for debugging this. The minimal fix then would be to change the 
> command in em-extpipe-test-2 to either of these:
> 
>    echo -N "bar" | rev *>temp

This doesn't work.  It still hangs when run interactively, as does the equivalent

      echo -N bar | sh -c "rev >temp"

>    *echo "bar" | rev *>temp

This works interactively, but I don't know the appropriate syntax for modifying 
the test.  Naively replacing each 'echo' by '*echo' caused the 'should-parse' to 
fail.
> One last[1] question: if you ran "echo -n bar | rev" in Cygwin Bash, does it 
> hang there too?

No.

> Maybe this is just a Cygwin limitation, or maybe Eshell is doing 
> something wrong with its built-in pipelines in this situation.

My guess is that it's the latter, but I don't know if it's worth pursuing this 
if Cygwin and EMBA are the only platforms on which there's a problem.  Of 
course, there might be other platforms and no one has reported it.

Once the test is fixed to succeed on Cygwin, we should probably revert the 
change that caused the extpipe tests to be skipped on EMBA, just to make sure 
that the same fix works there.

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-18 20:51                 ` Ken Brown
@ 2022-06-18 22:00                   ` Jim Porter
  2022-06-18 23:46                     ` Sean Whitton
  2022-06-19 16:02                     ` Ken Brown
  0 siblings, 2 replies; 36+ messages in thread
From: Jim Porter @ 2022-06-18 22:00 UTC (permalink / raw)
  To: Ken Brown, Sean Whitton, 56025, Lars Magne Ingebrigtsen

On 6/18/2022 1:51 PM, Ken Brown wrote:
> On 6/18/2022 3:02 PM, Jim Porter wrote:
>> On 6/18/2022 10:52 AM, Ken Brown wrote:
>>> No, I'm seeing the same results on Emacs 28.  On both Emacs 28 and 
>>> Emacs 29, rev is apparently not seeing EOF unless echo outputs a 
>>> newline, so rev keeps waiting for input.
>>
>> Ah ha! Thanks for debugging this. The minimal fix then would be to 
>> change the command in em-extpipe-test-2 to either of these:
>>
>>    echo -N "bar" | rev *>temp
> 
> This doesn't work.  It still hangs when run interactively...

Just to confirm, the above command hangs, but the following works, correct?

   echo -N "bar" | rev

>>    *echo "bar" | rev *>temp
> 
> This works interactively...

All this makes me think that we could be dealing with a race condition 
in how Eshell pipes I/O around. Maybe there's a timing issue in 
`eshell-close-target' where we end up not sending EOF to the "rev" (or 
"sh") process?

I'd be interested to see the results if you ran `M-x trace-function' for 
`eshell-close-target' and `process-status' before trying these commands. 
`process-status' should return `run' when called from inside 
`eshell-close-target'. If it doesn't, then we'd neglect to send EOF to 
"rev" (or "sh"), which would cause a hang like what you're seeing.

If that's not the issue, then I'm not sure what the issue would be 
exactly, but poking around in `eshell-close-target', 
`eshell-insertion-filter', and `eshell-sentinel' might yield some useful 
info.

> My guess is that it's the latter, but I don't know if it's worth 
> pursuing this if Cygwin and EMBA are the only platforms on which there's 
> a problem.  Of course, there might be other platforms and no one has 
> reported it.

I think if we could figure out the real issue, it would be great to fix 
it. Though if we can't, it would probably be ok to just fix the test by 
avoiding the issue.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-18 22:00                   ` Jim Porter
@ 2022-06-18 23:46                     ` Sean Whitton
  2022-06-19 16:02                     ` Ken Brown
  1 sibling, 0 replies; 36+ messages in thread
From: Sean Whitton @ 2022-06-18 23:46 UTC (permalink / raw)
  To: Jim Porter, Ken Brown, 56025, Lars Magne Ingebrigtsen

Hello,

On Sat 18 Jun 2022 at 03:00PM -07, Jim Porter wrote:

> I think if we could figure out the real issue, it would be great to fix
> it. Though if we can't, it would probably be ok to just fix the test by
> avoiding the issue.

We might first want to add another general Eshell test which shows up
the problem, though?

-- 
Sean Whitton





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-18 22:00                   ` Jim Porter
  2022-06-18 23:46                     ` Sean Whitton
@ 2022-06-19 16:02                     ` Ken Brown
  2022-06-24  1:18                       ` Ken Brown
  1 sibling, 1 reply; 36+ messages in thread
From: Ken Brown @ 2022-06-19 16:02 UTC (permalink / raw)
  To: Jim Porter, Sean Whitton, 56025, Lars Magne Ingebrigtsen

On 6/18/2022 6:00 PM, Jim Porter wrote:
> On 6/18/2022 1:51 PM, Ken Brown wrote:
>> On 6/18/2022 3:02 PM, Jim Porter wrote:
>>> On 6/18/2022 10:52 AM, Ken Brown wrote:
>>>> No, I'm seeing the same results on Emacs 28.  On both Emacs 28 and Emacs 29, 
>>>> rev is apparently not seeing EOF unless echo outputs a newline, so rev keeps 
>>>> waiting for input.
>>>
>>> Ah ha! Thanks for debugging this. The minimal fix then would be to change the 
>>> command in em-extpipe-test-2 to either of these:
>>>
>>>    echo -N "bar" | rev *>temp
>>
>> This doesn't work.  It still hangs when run interactively...
> 
> Just to confirm, the above command hangs, but the following works, correct?
> 
>    echo -N "bar" | rev

Correct.

>>>    *echo "bar" | rev *>temp
>>
>> This works interactively...
> 
> All this makes me think that we could be dealing with a race condition in how 
> Eshell pipes I/O around. Maybe there's a timing issue in `eshell-close-target' 
> where we end up not sending EOF to the "rev" (or "sh") process?

I think I've just discovered an anomaly in "rev" on Cygwin that could partially 
explain what I'm seeing.  I'll investigate that before proceeding further.

> I'd be interested to see the results if you ran `M-x trace-function' for 
> `eshell-close-target' and `process-status' before trying these commands. 
> `process-status' should return `run' when called from inside 
> `eshell-close-target'. If it doesn't, then we'd neglect to send EOF to "rev" (or 
> "sh"), which would cause a hang like what you're seeing.
> 
> If that's not the issue, then I'm not sure what the issue would be exactly, but 
> poking around in `eshell-close-target', `eshell-insertion-filter', and 
> `eshell-sentinel' might yield some useful info.
> 
>> My guess is that it's the latter, but I don't know if it's worth pursuing this 
>> if Cygwin and EMBA are the only platforms on which there's a problem.  Of 
>> course, there might be other platforms and no one has reported it.
> 
> I think if we could figure out the real issue, it would be great to fix it. 
> Though if we can't, it would probably be ok to just fix the test by avoiding the 
> issue.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-19 16:02                     ` Ken Brown
@ 2022-06-24  1:18                       ` Ken Brown
  2022-06-24  4:40                         ` Sean Whitton
  2022-06-24  6:07                         ` Eli Zaretskii
  0 siblings, 2 replies; 36+ messages in thread
From: Ken Brown @ 2022-06-24  1:18 UTC (permalink / raw)
  To: Jim Porter, Sean Whitton, 56025, Lars Magne Ingebrigtsen

On 6/19/2022 12:02 PM, Ken Brown wrote:
> On 6/18/2022 6:00 PM, Jim Porter wrote:
>> On 6/18/2022 1:51 PM, Ken Brown wrote:
>>> On 6/18/2022 3:02 PM, Jim Porter wrote:
>>>> On 6/18/2022 10:52 AM, Ken Brown wrote:
>>>>> No, I'm seeing the same results on Emacs 28.  On both Emacs 28 and Emacs 
>>>>> 29, rev is apparently not seeing EOF unless echo outputs a newline, so rev 
>>>>> keeps waiting for input.
>>>>
>>>> Ah ha! Thanks for debugging this. The minimal fix then would be to change 
>>>> the command in em-extpipe-test-2 to either of these:
>>>>
>>>>    echo -N "bar" | rev *>temp
>>>
>>> This doesn't work.  It still hangs when run interactively...
>>
>> Just to confirm, the above command hangs, but the following works, correct?
>>
>>    echo -N "bar" | rev
> 
> Correct.
> 
>>>>    *echo "bar" | rev *>temp
>>>
>>> This works interactively...
>>
>> All this makes me think that we could be dealing with a race condition in how 
>> Eshell pipes I/O around. Maybe there's a timing issue in `eshell-close-target' 
>> where we end up not sending EOF to the "rev" (or "sh") process?
> 
> I think I've just discovered an anomaly in "rev" on Cygwin that could partially 
> explain what I'm seeing.  I'll investigate that before proceeding further.

OK, I think I've got it sorted out now. The anomaly I referred to above is 
actually an anomaly in the stdio routines, not in "rev". It's discussed in item 
2 below. There are two issues.

1. I think there's a bug in eshell-close-target, in which it's assumed that 
sending C-d indicates end-of-file. This is only true if there's no input waiting 
to be read.  [In an interactive situation, this means we're at the beginning of 
a line.]  Otherwise, it takes a second C-d to indicate EOF.  So one C-d should 
suffice in the "echo -N bar" situation, but two are needed after "echo bar".

This bug probably went unnoticed because eshell-close-target was called twice in 
the case we were discussing, so process-send-eof was called twice.

2. On Cygwin and some other platforms, including Solaris 11.4 I think, it 
actually takes a third C-d, for reasons explained in the email thread starting 
at https://cygwin.com/pipermail/cygwin/2022-June/251672.html.  We're probably 
going to change this on Cygwin, but that still leaves other platforms.

The following patch resolves both issues:

diff --git a/lisp/eshell/esh-io.el b/lisp/eshell/esh-io.el
index 3644c1a18b..1c4131cb07 100644
--- a/lisp/eshell/esh-io.el
+++ b/lisp/eshell/esh-io.el
@@ -276,8 +276,8 @@ eshell-close-target
     ;; If we're redirecting to a process (via a pipe, or process
     ;; redirection), send it EOF so that it knows we're finished.
     ((eshell-processp target)
-    (if (eq (process-status target) 'run)
-       (process-send-eof target)))
+    (while (eq (process-status target) 'run)
+      (process-send-eof target)))

     ;; A plain function redirection needs no additional arguments
     ;; passed.

I'm about to go AFK for a few days.  If the eshell people agree that something 
like this patch should be installed, please go ahead.  I think it would then be 
worth re-enabling the extpipe tests on EMBA to see if the problem is fixed there 
too.

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-24  1:18                       ` Ken Brown
@ 2022-06-24  4:40                         ` Sean Whitton
  2022-06-24  6:07                         ` Eli Zaretskii
  1 sibling, 0 replies; 36+ messages in thread
From: Sean Whitton @ 2022-06-24  4:40 UTC (permalink / raw)
  To: Ken Brown, Jim Porter, 56025, Lars Magne Ingebrigtsen

Hello,

On Thu 23 Jun 2022 at 09:18pm -04, Ken Brown wrote:

> diff --git a/lisp/eshell/esh-io.el b/lisp/eshell/esh-io.el
> index 3644c1a18b..1c4131cb07 100644
> --- a/lisp/eshell/esh-io.el
> +++ b/lisp/eshell/esh-io.el
> @@ -276,8 +276,8 @@ eshell-close-target
>      ;; If we're redirecting to a process (via a pipe, or process
>      ;; redirection), send it EOF so that it knows we're finished.
>      ((eshell-processp target)
> -    (if (eq (process-status target) 'run)
> -       (process-send-eof target)))
> +    (while (eq (process-status target) 'run)
> +      (process-send-eof target)))
>
>      ;; A plain function redirection needs no additional arguments
>      ;; passed.
>
> I'm about to go AFK for a few days.  If the eshell people agree that something
> like this patch should be installed, please go ahead.  I think it would then be
> worth re-enabling the extpipe tests on EMBA to see if the problem is fixed there
> too.

I'm a bit queasy about an unbounded loop here.  Why not just try three
times?  Or, better, try twice, and a third time only if we're on a
platform where we know it's needed.

Many thanks for the investigative work.

-- 
Sean Whitton





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-24  1:18                       ` Ken Brown
  2022-06-24  4:40                         ` Sean Whitton
@ 2022-06-24  6:07                         ` Eli Zaretskii
  2022-06-24 16:53                           ` Jim Porter
  1 sibling, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2022-06-24  6:07 UTC (permalink / raw)
  To: Ken Brown; +Cc: jporterbugs, larsi, 56025, spwhitton

> Date: Thu, 23 Jun 2022 21:18:24 -0400
> From: Ken Brown <kbrown@cornell.edu>
> 
> 2. On Cygwin and some other platforms, including Solaris 11.4 I think, it 
> actually takes a third C-d, for reasons explained in the email thread starting 
> at https://cygwin.com/pipermail/cygwin/2022-June/251672.html.  We're probably 
> going to change this on Cygwin, but that still leaves other platforms.
> 
> The following patch resolves both issues:
> 
> diff --git a/lisp/eshell/esh-io.el b/lisp/eshell/esh-io.el
> index 3644c1a18b..1c4131cb07 100644
> --- a/lisp/eshell/esh-io.el
> +++ b/lisp/eshell/esh-io.el
> @@ -276,8 +276,8 @@ eshell-close-target
>      ;; If we're redirecting to a process (via a pipe, or process
>      ;; redirection), send it EOF so that it knows we're finished.
>      ((eshell-processp target)
> -    (if (eq (process-status target) 'run)
> -       (process-send-eof target)))
> +    (while (eq (process-status target) 'run)
> +      (process-send-eof target)))

Please add there comments explaining why this is done, or at least
point to relevant messages in this bug's discussion (NOT just to the
bug number, as the discussion is long and it will be hard to
understand what part of it is relevant).  Such "tricky" code should
always have comments explaining it.

Thanks.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-24  6:07                         ` Eli Zaretskii
@ 2022-06-24 16:53                           ` Jim Porter
  2022-06-24 22:23                             ` Sean Whitton
  0 siblings, 1 reply; 36+ messages in thread
From: Jim Porter @ 2022-06-24 16:53 UTC (permalink / raw)
  To: Eli Zaretskii, Ken Brown; +Cc: larsi, 56025, spwhitton

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On 6/23/2022 9:40 PM, Sean Whitton wrote:
 > I'm a bit queasy about an unbounded loop here.  Why not just try three
 > times?  Or, better, try twice, and a third time only if we're on a
 > platform where we know it's needed.

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.

 > Many thanks for the investigative work.

Agreed, this turned out to be a much subtler problem than I had 
initially suspected. Thanks!

On 6/23/2022 11:07 PM, Eli Zaretskii wrote:
> Please add there comments explaining why this is done, or at least
> point to relevant messages in this bug's discussion (NOT just to the
> bug number, as the discussion is long and it will be hard to
> understand what part of it is relevant).  Such "tricky" code should
> always have comments explaining it.

I added a comment explaining this to the best of my knowledge. There's 
one additional caveat I didn't mention there though, since it's only 
somewhat related. I believe this was mentioned earlier in the thread, 
but when Eshell creates a pipe, it routes both stdout and stderr to the 
next process's stdin (there's no way to control this behavior yet). When 
closing the handles from the initial process, it then calls 
`eshell-close-target' twice: once for stdout and once for stderr. Thus, 
with this patch, we'll call `process-send-eof' up to six times.

I'm not sure this is really a problem in practice today, but it might 
come up if Eshell gains the ability to redirect stdout and stderr 
separately.

[-- Attachment #2: 0001-When-closing-an-Eshell-process-target-send-EOF-three.patch --]
[-- Type: text/plain, Size: 2419 bytes --]

From a5f8dc8af6d199be8e3b09803835efa9d70b76a6 Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Fri, 24 Jun 2022 09:14:38 -0700
Subject: [PATCH] When closing an Eshell process target, send EOF three times

* lisp/eshell/esh-io.el (eshell-close-target): Send EOF 3 times.

* test/lisp/eshell/em-extpipe-tests.el (em-extpipe-tests--deftest):
Re-enable these tests on EMBA.

This patch is adapted by one from Ken Brown, who uncovered the reason
for this bug (bug#56025).
---
 lisp/eshell/esh-io.el                | 15 +++++++++++++--
 test/lisp/eshell/em-extpipe-tests.el |  1 -
 2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/lisp/eshell/esh-io.el b/lisp/eshell/esh-io.el
index 3644c1a18b..2d25186de7 100644
--- a/lisp/eshell/esh-io.el
+++ b/lisp/eshell/esh-io.el
@@ -276,8 +276,19 @@ eshell-close-target
    ;; If we're redirecting to a process (via a pipe, or process
    ;; redirection), send it EOF so that it knows we're finished.
    ((eshell-processp target)
-    (if (eq (process-status target) 'run)
-	(process-send-eof target)))
+    ;; According to the POSIX standards, sending EOF causes all bytes
+    ;; waiting to be read to be sent to the process immediately.
+    ;; Thus, if there are any bytes waiting, we need to send EOF
+    ;; twice: once to flush the buffer, and a second time to cause the
+    ;; next read() to return a size of 0.  However, some platforms
+    ;; (e.g. Solaris) actually require a *third* EOF.  Since sending
+    ;; extra EOFs while the process is running shouldn't break
+    ;; anything, we'll just send the maximum we'd ever need.  See
+    ;; bug#56025 for further details.
+    (let ((i 0))
+      (while (and (<= (cl-incf i) 3)
+                  (eq (process-status target) 'run))
+        (process-send-eof target))))
 
    ;; A plain function redirection needs no additional arguments
    ;; passed.
diff --git a/test/lisp/eshell/em-extpipe-tests.el b/test/lisp/eshell/em-extpipe-tests.el
index 3b84d763ac..29f5dc0551 100644
--- a/test/lisp/eshell/em-extpipe-tests.el
+++ b/test/lisp/eshell/em-extpipe-tests.el
@@ -71,7 +71,6 @@ em-extpipe-tests--deftest
        (skip-unless shell-file-name)
        (skip-unless shell-command-switch)
        (skip-unless (executable-find shell-file-name))
-       (skip-unless (not (getenv "EMACS_EMBA_CI")))
        (let ((input ,input))
          (with-temp-eshell ,@body)))))
 
-- 
2.25.1


^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-24 16:53                           ` Jim Porter
@ 2022-06-24 22:23                             ` Sean Whitton
  2022-06-24 23:03                               ` Jim Porter
  0 siblings, 1 reply; 36+ messages in thread
From: Sean Whitton @ 2022-06-24 22:23 UTC (permalink / raw)
  To: Jim Porter, Eli Zaretskii, Ken Brown; +Cc: larsi, 56025

Hello,

On Fri 24 Jun 2022 at 09:53AM -07, Jim Porter wrote:

> On 6/23/2022 9:40 PM, Sean Whitton wrote:
>  > I'm a bit queasy about an unbounded loop here.  Why not just try three
>  > times?  Or, better, try twice, and a third time only if we're on a
>  > platform where we know it's needed.
>
> 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.

-- 
Sean Whitton





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-24 22:23                             ` Sean Whitton
@ 2022-06-24 23:03                               ` Jim Porter
  2022-06-25  5:34                                 ` Eli Zaretskii
  2022-06-26 17:12                                 ` Sean Whitton
  0 siblings, 2 replies; 36+ messages in thread
From: Jim Porter @ 2022-06-24 23:03 UTC (permalink / raw)
  To: Sean Whitton, Eli Zaretskii, Ken Brown; +Cc: larsi, 56025

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





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-24 23:03                               ` Jim Porter
@ 2022-06-25  5:34                                 ` Eli Zaretskii
  2022-06-25 16:13                                   ` Jim Porter
  2022-06-26 17:12                                 ` Sean Whitton
  1 sibling, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2022-06-25  5:34 UTC (permalink / raw)
  To: Jim Porter; +Cc: larsi, 56025, spwhitton, kbrown

> Cc: larsi@gnus.org, 56025@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Fri, 24 Jun 2022 16:03:13 -0700
> 
> 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.

Perhaps some reference to this should also be in the comments.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-25  5:34                                 ` Eli Zaretskii
@ 2022-06-25 16:13                                   ` Jim Porter
  2022-06-25 16:53                                     ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Jim Porter @ 2022-06-25 16:13 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, 56025, spwhitton, kbrown

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On 6/24/2022 10:34 PM, Eli Zaretskii wrote:
>> Cc: larsi@gnus.org, 56025@debbugs.gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>> Date: Fri, 24 Jun 2022 16:03:13 -0700
>>
>> 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.
> 
> Perhaps some reference to this should also be in the comments.

How about this patch? I added a reference to the specific section of the 
POSIX specification so that it's (hopefully) easy for people to look up 
if they need further details.

[-- Attachment #2: 0001-When-closing-an-Eshell-process-target-send-EOF-three.patch --]
[-- Type: text/plain, Size: 2493 bytes --]

From 8664e6f3dc9e40d1fae8a44dc4c444ab40510a18 Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Fri, 24 Jun 2022 09:14:38 -0700
Subject: [PATCH] When closing an Eshell process target, send EOF three times

* lisp/eshell/esh-io.el (eshell-close-target): Send EOF 3 times.

* test/lisp/eshell/em-extpipe-tests.el (em-extpipe-tests--deftest):
Re-enable these tests on EMBA.

This patch is adapted by one from Ken Brown, who uncovered the reason
for this bug (bug#56025).
---
 lisp/eshell/esh-io.el                | 16 ++++++++++++++--
 test/lisp/eshell/em-extpipe-tests.el |  1 -
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/lisp/eshell/esh-io.el b/lisp/eshell/esh-io.el
index 3644c1a18b..c035890ddf 100644
--- a/lisp/eshell/esh-io.el
+++ b/lisp/eshell/esh-io.el
@@ -276,8 +276,20 @@ eshell-close-target
    ;; If we're redirecting to a process (via a pipe, or process
    ;; redirection), send it EOF so that it knows we're finished.
    ((eshell-processp target)
-    (if (eq (process-status target) 'run)
-	(process-send-eof target)))
+    ;; According to POSIX.1-2017, section 11.1.9, sending EOF causes
+    ;; all bytes waiting to be read to be sent to the process
+    ;; immediately.  Thus, if there are any bytes waiting, we need to
+    ;; send EOF twice: once to flush the buffer, and a second time to
+    ;; cause the next read() to return a size of 0, indicating
+    ;; end-of-file to the reading process.  However, some platforms
+    ;; (e.g. Solaris) actually require sending a *third* EOF.  Since
+    ;; sending extra EOFs while the process is running shouldn't break
+    ;; anything, we'll just send the maximum we'd ever need.  See
+    ;; bug#56025 for further details.
+    (let ((i 0))
+      (while (and (<= (cl-incf i) 3)
+                  (eq (process-status target) 'run))
+        (process-send-eof target))))
 
    ;; A plain function redirection needs no additional arguments
    ;; passed.
diff --git a/test/lisp/eshell/em-extpipe-tests.el b/test/lisp/eshell/em-extpipe-tests.el
index 3b84d763ac..29f5dc0551 100644
--- a/test/lisp/eshell/em-extpipe-tests.el
+++ b/test/lisp/eshell/em-extpipe-tests.el
@@ -71,7 +71,6 @@ em-extpipe-tests--deftest
        (skip-unless shell-file-name)
        (skip-unless shell-command-switch)
        (skip-unless (executable-find shell-file-name))
-       (skip-unless (not (getenv "EMACS_EMBA_CI")))
        (let ((input ,input))
          (with-temp-eshell ,@body)))))
 
-- 
2.25.1


^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-25 16:13                                   ` Jim Porter
@ 2022-06-25 16:53                                     ` Eli Zaretskii
  2022-06-26 16:27                                       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 36+ messages in thread
From: Eli Zaretskii @ 2022-06-25 16:53 UTC (permalink / raw)
  To: Jim Porter; +Cc: larsi, 56025, spwhitton, kbrown

> Cc: larsi@gnus.org, 56025@debbugs.gnu.org, spwhitton@email.arizona.edu,
>  kbrown@cornell.edu
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Sat, 25 Jun 2022 09:13:46 -0700
> 
> >>     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.
> > 
> > Perhaps some reference to this should also be in the comments.
> 
> How about this patch? I added a reference to the specific section of the 
> POSIX specification so that it's (hopefully) easy for people to look up 
> if they need further details.

LGTM, thanks.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-25 16:53                                     ` Eli Zaretskii
@ 2022-06-26 16:27                                       ` Lars Ingebrigtsen
  0 siblings, 0 replies; 36+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-26 16:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Jim Porter, 56025, spwhitton, kbrown

Eli Zaretskii <eliz@gnu.org> writes:

>> How about this patch? I added a reference to the specific section of the 
>> POSIX specification so that it's (hopefully) easy for people to look up 
>> if they need further details.
>
> LGTM, thanks.

Pushed to Emacs 29 now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-24 23:03                               ` Jim Porter
  2022-06-25  5:34                                 ` Eli Zaretskii
@ 2022-06-26 17:12                                 ` Sean Whitton
  2022-06-26 17:22                                   ` Jim Porter
  1 sibling, 1 reply; 36+ messages in thread
From: Sean Whitton @ 2022-06-26 17:12 UTC (permalink / raw)
  To: Jim Porter, Eli Zaretskii, Ken Brown; +Cc: larsi, 56025

Hello,

On Fri 24 Jun 2022 at 04:03pm -07, Jim Porter wrote:

>    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

The text states unconditionally that when an EOF is received it is
discarded by the OS.  So we can infer that it's fine to send three,
according to the standard -- it's not just that it happens to work.

Thanks again for working on this.

-- 
Sean Whitton





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-26 17:12                                 ` Sean Whitton
@ 2022-06-26 17:22                                   ` Jim Porter
  2022-06-26 21:11                                     ` Sean Whitton
  0 siblings, 1 reply; 36+ messages in thread
From: Jim Porter @ 2022-06-26 17:22 UTC (permalink / raw)
  To: Sean Whitton, Eli Zaretskii, Ken Brown; +Cc: larsi, 56025

On 6/26/2022 10:12 AM, Sean Whitton wrote:
> On Fri 24 Jun 2022 at 04:03pm -07, Jim Porter wrote:
> 
>>     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
> 
> The text states unconditionally that when an EOF is received it is
> discarded by the OS.  So we can infer that it's fine to send three,
> according to the standard -- it's not just that it happens to work.
> 
> Thanks again for working on this.

Ah, good catch. I glossed over the last sentence in that paragraph in 
the spec (hence why I didn't copy-paste it).





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-26 17:22                                   ` Jim Porter
@ 2022-06-26 21:11                                     ` Sean Whitton
  2022-06-27 13:25                                       ` Ken Brown
  0 siblings, 1 reply; 36+ messages in thread
From: Sean Whitton @ 2022-06-26 21:11 UTC (permalink / raw)
  To: Jim Porter, Eli Zaretskii, Ken Brown; +Cc: larsi, 56025

Hello,

On Sun 26 Jun 2022 at 10:22AM -07, Jim Porter wrote:

> On 6/26/2022 10:12 AM, Sean Whitton wrote:
>> On Fri 24 Jun 2022 at 04:03pm -07, Jim Porter wrote:
>>
>>>     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
>>
>> The text states unconditionally that when an EOF is received it is
>> discarded by the OS.  So we can infer that it's fine to send three,
>> according to the standard -- it's not just that it happens to work.
>>
>> Thanks again for working on this.
>
> Ah, good catch. I glossed over the last sentence in that paragraph in
> the spec (hence why I didn't copy-paste it).

I was actually thinking it was implied by the first sentence of what you
quoted.

-- 
Sean Whitton





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-26 21:11                                     ` Sean Whitton
@ 2022-06-27 13:25                                       ` Ken Brown
  2022-06-27 15:51                                         ` Michael Albinus
  2022-06-27 19:18                                         ` Jim Porter
  0 siblings, 2 replies; 36+ messages in thread
From: Ken Brown @ 2022-06-27 13:25 UTC (permalink / raw)
  To: Sean Whitton, Jim Porter, Eli Zaretskii; +Cc: larsi, 56025

Thanks to all of you for working on this while I was gone.  Unfortunately, the 
problem is still present on Cygwin.  In my haste to get away, I neglected to 
mention that there is apparently a timing issue in Eshell on Cygwin, so that 
even three EOFs do not always suffice to kill the process.

My test case is to run

   echo bar | sh -c rev

in Eshell.  For reasons I don't understand, EOF almost always has to be sent 
more than 3 times times before the "sh" process dies.  The maximum I've observed 
is 93.  Inserting "(sit-for 0.01)" after each EOF eliminates the need for extra 
EOFs; this is why I referred to the problem as a timing issue.

I propose the following workaround:

--- a/lisp/eshell/esh-io.el
+++ b/lisp/eshell/esh-io.el
@@ -284,10 +284,16 @@ eshell-close-target
      ;; end-of-file to the reading process.  However, some platforms
      ;; (e.g. Solaris) actually require sending a *third* EOF.  Since
      ;; sending extra EOFs while the process is running shouldn't break
-    ;; anything, we'll just send the maximum we'd ever need.  See
-    ;; bug#56025 for further details.
-    (let ((i 0))
-      (while (and (<= (cl-incf i) 3)
+    ;; anything, we'll send up to three on all platforms.
+
+    ;; There's an extra wrinkle on Cygwin where, apparently due to an
+    ;; unknown timing issue, it sometimes takes more than three EOFs
+    ;; to kill the process.  (This only happens in Eshell, not in an
+    ;; ordinary Cygwin shell.)  We work around this problem by sending
+    ;; up to 1000 EOFs on Cygwin.  See bug#56025 for further details.
+    (let ((i 0)
+          (n (if (eq system-type 'cygwin) 1000 3)))
+      (while (and (<= (cl-incf i) n)
                    (eq (process-status target) 'run))
          (process-send-eof target))))


Ken

P.S. Has anyone checked to see if the extpipe tests are now passing on EMBA?  If 
not, maybe the workaround is needed there too.  Alternatively, we could simply 
use the workaround on all platforms.  I don't see what harm it could do.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-27 13:25                                       ` Ken Brown
@ 2022-06-27 15:51                                         ` Michael Albinus
  2022-06-27 16:22                                           ` Ken Brown
  2022-06-27 19:18                                         ` Jim Porter
  1 sibling, 1 reply; 36+ messages in thread
From: Michael Albinus @ 2022-06-27 15:51 UTC (permalink / raw)
  To: Ken Brown; +Cc: larsi, Jim Porter, Eli Zaretskii, 56025, Sean Whitton

Ken Brown <kbrown@cornell.edu> writes:

Hi Ken,

> P.S. Has anyone checked to see if the extpipe tests are now passing on
> EMBA?

Seems to work there. <https://emba.gnu.org/emacs/emacs/-/jobs/48285>

Best regards, Michael.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-27 15:51                                         ` Michael Albinus
@ 2022-06-27 16:22                                           ` Ken Brown
  2022-06-27 19:13                                             ` bug#56025: [EXT]Re: " Sean Whitton
  0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2022-06-27 16:22 UTC (permalink / raw)
  To: Michael Albinus; +Cc: larsi, Jim Porter, Eli Zaretskii, 56025, Sean Whitton

On 6/27/2022 11:51 AM, Michael Albinus wrote:>> P.S. Has anyone checked to see 
if the extpipe tests are now passing on
>> EMBA?
> 
> Seems to work there. <https://emba.gnu.org/emacs/emacs/-/jobs/48285>

Thanks, Michael.  In that case we should probably go ahead with the Cygwin fix, 
but I'll wait to hear from Eli or Lars.

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: [EXT]Re: bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-27 16:22                                           ` Ken Brown
@ 2022-06-27 19:13                                             ` Sean Whitton
  2022-06-27 21:17                                               ` Ken Brown
  0 siblings, 1 reply; 36+ messages in thread
From: Sean Whitton @ 2022-06-27 19:13 UTC (permalink / raw)
  To: Ken Brown, Michael Albinus; +Cc: Jim Porter, Eli Zaretskii, 56025, larsi

Hello,

On Mon 27 Jun 2022 at 12:22pm -04, Ken Brown wrote:

> External Email
>
> On 6/27/2022 11:51 AM, Michael Albinus wrote:>> P.S. Has anyone checked to see
> if the extpipe tests are now passing on
>>> EMBA?
>>
>> Seems to work there. <https://emba.gnu.org/emacs/emacs/-/jobs/48285>
>
> Thanks, Michael.  In that case we should probably go ahead with the Cygwin fix,
> but I'll wait to hear from Eli or Lars.

The three times fix or the thousand times fix, do you mean?

-- 
Sean Whitton





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-27 13:25                                       ` Ken Brown
  2022-06-27 15:51                                         ` Michael Albinus
@ 2022-06-27 19:18                                         ` Jim Porter
  2022-06-27 21:19                                           ` Ken Brown
  1 sibling, 1 reply; 36+ messages in thread
From: Jim Porter @ 2022-06-27 19:18 UTC (permalink / raw)
  To: Ken Brown, Sean Whitton, Eli Zaretskii; +Cc: larsi, 56025

On 6/27/2022 6:25 AM, Ken Brown wrote:
> Thanks to all of you for working on this while I was gone.  
> Unfortunately, the problem is still present on Cygwin.  In my haste to 
> get away, I neglected to mention that there is apparently a timing issue 
> in Eshell on Cygwin, so that even three EOFs do not always suffice to 
> kill the process.
> 
> My test case is to run
> 
>    echo bar | sh -c rev
> 
> in Eshell.  For reasons I don't understand, EOF almost always has to be 
> sent more than 3 times times before the "sh" process dies.  The maximum 
> I've observed is 93.  Inserting "(sit-for 0.01)" after each EOF 
> eliminates the need for extra EOFs; this is why I referred to the 
> problem as a timing issue.
> 
> I propose the following workaround:
> 
> --- a/lisp/eshell/esh-io.el
> +++ b/lisp/eshell/esh-io.el
> @@ -284,10 +284,16 @@ eshell-close-target
>       ;; end-of-file to the reading process.  However, some platforms
>       ;; (e.g. Solaris) actually require sending a *third* EOF.  Since
>       ;; sending extra EOFs while the process is running shouldn't break
> -    ;; anything, we'll just send the maximum we'd ever need.  See
> -    ;; bug#56025 for further details.
> -    (let ((i 0))
> -      (while (and (<= (cl-incf i) 3)
> +    ;; anything, we'll send up to three on all platforms.
> +
> +    ;; There's an extra wrinkle on Cygwin where, apparently due to an
> +    ;; unknown timing issue, it sometimes takes more than three EOFs
> +    ;; to kill the process.  (This only happens in Eshell, not in an
> +    ;; ordinary Cygwin shell.)  We work around this problem by sending
> +    ;; up to 1000 EOFs on Cygwin.  See bug#56025 for further details.
> +    (let ((i 0)
> +          (n (if (eq system-type 'cygwin) 1000 3)))
> +      (while (and (<= (cl-incf i) n)
>                     (eq (process-status target) 'run))
>           (process-send-eof target))))

I'd be very hesitant to do this, since as you mention above, this seems 
like a timing issue, and it's entirely possible that there are other, 
more widespread issues on Cygwin here. We'd also want to check the 
system that the process is actually running on; otherwise, remoting into 
a Cygwin system (via Tramp) would still exhibit the problem. I'll see if 
I can get a Cygwin environment up to test things out in the next week-ish.

If there's no other way that we can come up with here, I'd lean towards 
a defcustom so that users can tweak this if needed.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: [EXT]Re: bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-27 19:13                                             ` bug#56025: [EXT]Re: " Sean Whitton
@ 2022-06-27 21:17                                               ` Ken Brown
  0 siblings, 0 replies; 36+ messages in thread
From: Ken Brown @ 2022-06-27 21:17 UTC (permalink / raw)
  To: Sean Whitton, Michael Albinus; +Cc: Jim Porter, Eli Zaretskii, 56025, larsi

On 6/27/2022 3:13 PM, Sean Whitton wrote:
> Hello,
> 
> On Mon 27 Jun 2022 at 12:22pm -04, Ken Brown wrote:
> 
>> External Email
>>
>> On 6/27/2022 11:51 AM, Michael Albinus wrote:>> P.S. Has anyone checked to see
>> if the extpipe tests are now passing on
>>>> EMBA?
>>>
>>> Seems to work there. <https://emba.gnu.org/emacs/emacs/-/jobs/48285>
>>
>> Thanks, Michael.  In that case we should probably go ahead with the Cygwin fix,
>> but I'll wait to hear from Eli or Lars.
> 
> The three times fix or the thousand times fix, do you mean?

I meant the fix that's 1000 on Cygwin and 3 elsewhere.  But let's see if Jim 
comes up with something better.

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-27 19:18                                         ` Jim Porter
@ 2022-06-27 21:19                                           ` Ken Brown
  2022-07-01  3:52                                             ` Jim Porter
  0 siblings, 1 reply; 36+ messages in thread
From: Ken Brown @ 2022-06-27 21:19 UTC (permalink / raw)
  To: Jim Porter, Sean Whitton, Eli Zaretskii; +Cc: larsi, 56025

On 6/27/2022 3:18 PM, Jim Porter wrote:
> On 6/27/2022 6:25 AM, Ken Brown wrote:
>> Thanks to all of you for working on this while I was gone. Unfortunately, the 
>> problem is still present on Cygwin.  In my haste to get away, I neglected to 
>> mention that there is apparently a timing issue in Eshell on Cygwin, so that 
>> even three EOFs do not always suffice to kill the process.
>>
>> My test case is to run
>>
>>    echo bar | sh -c rev
>>
>> in Eshell.  For reasons I don't understand, EOF almost always has to be sent 
>> more than 3 times times before the "sh" process dies.  The maximum I've 
>> observed is 93.  Inserting "(sit-for 0.01)" after each EOF eliminates the need 
>> for extra EOFs; this is why I referred to the problem as a timing issue.
>>
>> I propose the following workaround:
>>
>> --- a/lisp/eshell/esh-io.el
>> +++ b/lisp/eshell/esh-io.el
>> @@ -284,10 +284,16 @@ eshell-close-target
>>       ;; end-of-file to the reading process.  However, some platforms
>>       ;; (e.g. Solaris) actually require sending a *third* EOF.  Since
>>       ;; sending extra EOFs while the process is running shouldn't break
>> -    ;; anything, we'll just send the maximum we'd ever need.  See
>> -    ;; bug#56025 for further details.
>> -    (let ((i 0))
>> -      (while (and (<= (cl-incf i) 3)
>> +    ;; anything, we'll send up to three on all platforms.
>> +
>> +    ;; There's an extra wrinkle on Cygwin where, apparently due to an
>> +    ;; unknown timing issue, it sometimes takes more than three EOFs
>> +    ;; to kill the process.  (This only happens in Eshell, not in an
>> +    ;; ordinary Cygwin shell.)  We work around this problem by sending
>> +    ;; up to 1000 EOFs on Cygwin.  See bug#56025 for further details.
>> +    (let ((i 0)
>> +          (n (if (eq system-type 'cygwin) 1000 3)))
>> +      (while (and (<= (cl-incf i) n)
>>                     (eq (process-status target) 'run))
>>           (process-send-eof target))))
> 
> I'd be very hesitant to do this, since as you mention above, this seems like a 
> timing issue, and it's entirely possible that there are other, more widespread 
> issues on Cygwin here. We'd also want to check the system that the process is 
> actually running on; otherwise, remoting into a Cygwin system (via Tramp) would 
> still exhibit the problem. I'll see if I can get a Cygwin environment up to test 
> things out in the next week-ish.

OK, thanks.  Let me know if you need any help with that.

> If there's no other way that we can come up with here, I'd lean towards a 
> defcustom so that users can tweak this if needed.

Sounds good.

Ken





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-06-27 21:19                                           ` Ken Brown
@ 2022-07-01  3:52                                             ` Jim Porter
  2022-07-01  3:58                                               ` Jim Porter
  0 siblings, 1 reply; 36+ messages in thread
From: Jim Porter @ 2022-07-01  3:52 UTC (permalink / raw)
  To: Ken Brown, Sean Whitton, Eli Zaretskii; +Cc: larsi, 56025

On 6/27/2022 2:19 PM, Ken Brown wrote:
> On 6/27/2022 3:18 PM, Jim Porter wrote:
>> I'd be very hesitant to do this, since as you mention above, this 
>> seems like a timing issue, and it's entirely possible that there are 
>> other, more widespread issues on Cygwin here. We'd also want to check 
>> the system that the process is actually running on; otherwise, 
>> remoting into a Cygwin system (via Tramp) would still exhibit the 
>> problem. I'll see if I can get a Cygwin environment up to test things 
>> out in the next week-ish.
> 
> OK, thanks.  Let me know if you need any help with that.

Ok, I've got Cygwin set up (though I'm just using the prebuilt Cygwin 
Emacs for now). I can confirm that the following hangs until I send 
another EOF via `C-c C-d':

   echo hi | rev

However, if I evaluate the following first, the above command works just 
fine:

   (add-to-list 'eshell-needs-pipe "rev")

Normally, Eshell starts each process using ptys to control them. 
However, the above Elisp code tells Eshell to use a pipe for "rev"[1]. 
I'm not totally clear on all the subtleties here, but it seems to me 
that it would make more sense for rev to use a pipe for its stdin and a 
pty for its stdout. That's not possible with subprocesses in Emacs 
though (as far as I know).

However, I don't think this fully answers things, since I also see 
inconsistent results if I run "echo hi | rev" a bunch of times. 
Sometimes it prints "ih" and then I need to hit `C-c C-d` once to stop 
it. Other times it doesn't print anything and I need to hit `C-c C-d' 
twice. There must be some kind of race condition, maybe in Emacs's 
src/process.c?

Hopefully this helps get us closer to a proper answer here though...

[1] Only when rev is being piped *to* in an Eshell pipeline.





^ permalink raw reply	[flat|nested] 36+ messages in thread

* bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin
  2022-07-01  3:52                                             ` Jim Porter
@ 2022-07-01  3:58                                               ` Jim Porter
  0 siblings, 0 replies; 36+ messages in thread
From: Jim Porter @ 2022-07-01  3:58 UTC (permalink / raw)
  To: Ken Brown, Sean Whitton, Eli Zaretskii; +Cc: larsi, 56025

On 6/30/2022 8:52 PM, Jim Porter wrote:
> Normally, Eshell starts each process using ptys to control them. 
> However, the above Elisp code tells Eshell to use a pipe for "rev"[1]. 
> I'm not totally clear on all the subtleties here, but it seems to me 
> that it would make more sense for rev to use a pipe for its stdin and a 
> pty for its stdout. That's not possible with subprocesses in Emacs 
> though (as far as I know).

Oh, I forgot to mention that bug#56013 might be related to this in some 
way, since it exhibits some problems with ptys when used in Eshell 
pipelines too.





^ permalink raw reply	[flat|nested] 36+ messages in thread

end of thread, other threads:[~2022-07-01  3:58 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-16 18:30 bug#56025: 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin Ken Brown
2022-06-16 19:30 ` Sean Whitton
2022-06-16 22:01   ` Ken Brown
2022-06-17 13:39     ` Ken Brown
2022-06-18  0:57       ` Sean Whitton
2022-06-18  2:07         ` Ken Brown
2022-06-18  2:35           ` Ken Brown
2022-06-18  3:50           ` Jim Porter
2022-06-18 17:52             ` Ken Brown
2022-06-18 19:02               ` Jim Porter
2022-06-18 20:51                 ` Ken Brown
2022-06-18 22:00                   ` Jim Porter
2022-06-18 23:46                     ` Sean Whitton
2022-06-19 16:02                     ` Ken Brown
2022-06-24  1:18                       ` Ken Brown
2022-06-24  4:40                         ` Sean Whitton
2022-06-24  6:07                         ` Eli Zaretskii
2022-06-24 16:53                           ` Jim Porter
2022-06-24 22:23                             ` Sean Whitton
2022-06-24 23:03                               ` Jim Porter
2022-06-25  5:34                                 ` Eli Zaretskii
2022-06-25 16:13                                   ` Jim Porter
2022-06-25 16:53                                     ` Eli Zaretskii
2022-06-26 16:27                                       ` Lars Ingebrigtsen
2022-06-26 17:12                                 ` Sean Whitton
2022-06-26 17:22                                   ` Jim Porter
2022-06-26 21:11                                     ` Sean Whitton
2022-06-27 13:25                                       ` Ken Brown
2022-06-27 15:51                                         ` Michael Albinus
2022-06-27 16:22                                           ` Ken Brown
2022-06-27 19:13                                             ` bug#56025: [EXT]Re: " Sean Whitton
2022-06-27 21:17                                               ` Ken Brown
2022-06-27 19:18                                         ` Jim Porter
2022-06-27 21:19                                           ` Ken Brown
2022-07-01  3:52                                             ` Jim Porter
2022-07-01  3:58                                               ` Jim Porter

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).