bug#56025: [WIP PATCH] 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin

[Jim Porter <jporterbugs@gmail.com>]

On 7/17/2022 11:26 AM, Eli Zaretskii wrote:
>> Cc: larsi@gnus.org, 56025@debbugs.gnu.org, spwhitton@email.arizona.edu,
>>   kbrown@cornell.edu
>> From: Jim Porter <jporterbugs@gmail.com>
>> Date: Sun, 17 Jul 2022 10:44:26 -0700
>>
>> My patch adds support for `make-process' to use a PTY only for the child
>> process's stdin or its stdout (in addition to the preexisting behaviors
>> of PTY for both or neither). This then lets Eshell request a pipe for
>> foo's stdout and bar's stdin, while using PTYs for foo's stdin and bar's
>> stdout:
>>
>>     Before:
>>       [pty 1] -> foo -> [pty 1] -> Eshell -> [pty 2] -> bar -> [pty 2]
>>
>>     After:
>>       [pty 1] -> foo -> [pipe] -> Eshell -> [pipe] -> bar -> [pty 2]
> 
> This assumes that we never want foo to behave as it does when
> displaying on a terminal device.  Are we sure we will never want that?
> E.g., what about the equivalent of "fgrep ... | less" -- don't we want
> fgrep to produce colorized output as it does when it writes to a
> terminal device?

Well, for something like fgrep, the usual way to do this in a regular 
shell would be "fgrep --color=always ... | less", which should work the 
same in Eshell. There are a few caveats to this though:

1. "fgrep" is actually a built-in Eshell command that opens a 
compilation buffer and runs "grep -F ..." in it, so piping it to "less" 
normally isn't necessary. Still, you could always use the external fgrep 
program by specifying the full path or saying "*fgrep" though.

2. External commands see Eshell as a dumb terminal, and so they usually 
won't colorize their output in the first place without the user forcing 
it. Piping to "less" doesn't change the situation there.

3. Piping to "less" is probably going to have problems, even with this 
change. Eshell considers less to be a "visual command", so it opens it 
up in an M-x term buffer (and I don't think the Eshell->term code is 
able to support pipelines like this yet). Even if that were fixed, I 
think it would be tricky to get less working in Eshell. That said, I 
have a plan to make a built-in version of less for Eshell written in 
Elisp that should do pretty much what Eshell users would expect. This is 
a complex project though (I started it in February!), and I have a few 
more preliminary changes to make to Eshell to make this easier to do.

> Perhaps the use of pipes should be controllable?

However, with all the above said, I think we *do* want the use of pipes 
to be controllable in at least some cases. For example, due to the 
differences between Eshell and regular shells, commands like "xdg-open" 
don't work properly (this is bug#56013). It would be nice if Eshell 
could make those commands Just Work, but I'm not sure that's feasible 
given how Eshell works. I think the most straightforward way to resolve 
that would be to declare "xdg-open" (and similar commands) as *always* 
using pipes, no matter what. Maybe there are commands that always want a 
PTY too.

It wouldn't be too hard to have a mapping from command names to 
connection-types that would handle this. It would be sort of like the 
`eshell-needs-pipe-p' code that I removed in my WIP patch, but with 
finer-grained control.