On 7/17/2022 10:26 PM, Jim Porter wrote:
> On 7/17/2022 2:59 PM, Ken Brown wrote:
>> It does work for me too.  Thanks!
> 
> Great! This should make Eshell behave a bit more similarly to other 
> shells, so hopefully this will help prevent other issues in this area.

Ok, I *think* this is done. The patches have docs/tests that should 
hopefully explain everything in detail, but here's a high-level overview:

Patch 1:
--------

Add the ability to pass a cons cell for `:connection-type' to 
`make-process'. This lets you specify whether to use a pipe or pty 
independently for the input and output of the subprocess. This also 
removes the restriction that specifying `:stderr' forces 
`:connection-type' to be `pipe'. Now, it only makes stderr use a pipe.

This should be enough to fix the test failures mentioned in this bug, 
and should also make Eshell pipelines work more like in other shells: 
normally, when executing something like `foo | bar', foo's stdout and 
bar's stdin are pipes.[1]

I also removed the `eshell-needs-pipe-p' function since it's not 
necessary in its current form anymore. However, a new function along 
these lines might help to resolve bug#56013. I looked into this briefly 
and it's not terribly complicated, but it would take a bit of work to 
get right, so I think it'd be best to do it separately.

Patch 2:
--------

Add the ability to check whether each of a subprocess's `stdin', 
`stdout', or `stderr' are TTYs or pipes by passing one of those symbols 
as the second argument to `process-tty-name'. This lets us avoid the 
"send 3 EOFs" behavior most of the time in Eshell. (Note that if a user 
created a subprocess some other way and connected it via Eshell, they 
might need the 3 EOFs behavior, hence why I kept that code around.)

I debated whether `process-tty-name' was the right place to do this or 
if a new `process-connection-type' function would be better, but I went 
with this way in the end. I don't really have a strong preference though.

--------

I added tests for this, and they all pass for me, though admittedly I 
didn't run the entire Emacs test suite against these patches yet...

[1] Note that currently, Eshell always pipes both stdout and stderr (see 
bug#21605). I'm tinkering with a patch for this too.