From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.bugs Subject: bug#56025: [WIP PATCH] 29.0.50; em-extpipe-test-2 times out on EMBA and Cygwin Date: Sun, 17 Jul 2022 11:51:08 -0700 Message-ID: <5c7bb6ff-f93e-0583-3e88-b5b8d7c00606@gmail.com> References: <8e21db9c-0100-998e-f280-81304e7ff61a@cornell.edu> <040b3a36-459b-a94d-f879-7f45aac50bda@cornell.edu> <83sfnud26o.fsf@gnu.org> <96e47ba7-efaa-b6df-dd98-60f09068e68c@gmail.com> <874k097lbh.fsf@melete.silentflame.com> <8735frmjrr.fsf@athena.silentflame.com> <4676f52c-4758-38df-f0f4-dbcb5d848c1b@gmail.com> <8735fr2kq6.fsf@melete.silentflame.com> <10cf6a90-f86a-b0df-4dc2-c258b7494158@gmail.com> <18e79c02-3a2a-77d1-3798-33711f52d6b9@cornell.edu> <19c66901-2eeb-1f40-17a4-4ed54827e065@gmail.com> <5990de80-63a5-ac9b-1a11-c814aa9e38f2@gmail.com> <3779ea08-f481-5fb5-3257-ca9fa7c604bc@cornell.edu> <60cf587b-5d83-31d6-f0af-56979b221425@gmail.com> <83bktoqnru.fsf@gnu.org> <5f9b3680-d840-cc1d-14a6-1c8f71c30e62@gmail.com> <83lesrppcs.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29290"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 56025@debbugs.gnu.org, spwhitton@email.arizona.edu, kbrown@cornell.edu To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 17 20:52:17 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oD9NJ-0007TS-6u for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Jul 2022 20:52:17 +0200 Original-Received: from localhost ([::1]:48572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oD9NH-0003kJ-Oy for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 17 Jul 2022 14:52:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oD9N4-0003k2-PC for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2022 14:52:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50799) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oD9N4-00035U-E2 for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2022 14:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oD9N4-0005ij-8x for bug-gnu-emacs@gnu.org; Sun, 17 Jul 2022 14:52:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jim Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Jul 2022 18:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56025 X-GNU-PR-Package: emacs Original-Received: via spool by 56025-submit@debbugs.gnu.org id=B56025.165808387921931 (code B ref 56025); Sun, 17 Jul 2022 18:52:02 +0000 Original-Received: (at 56025) by debbugs.gnu.org; 17 Jul 2022 18:51:19 +0000 Original-Received: from localhost ([127.0.0.1]:48558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oD9MM-0005hf-EM for submit@debbugs.gnu.org; Sun, 17 Jul 2022 14:51:18 -0400 Original-Received: from mail-pg1-f173.google.com ([209.85.215.173]:41749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oD9MK-0005hR-7Z for 56025@debbugs.gnu.org; Sun, 17 Jul 2022 14:51:17 -0400 Original-Received: by mail-pg1-f173.google.com with SMTP id 23so8825714pgc.8 for <56025@debbugs.gnu.org>; Sun, 17 Jul 2022 11:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=jv3kh4sN2QHe8ahB8Q2g7jI3TtUGlAvNgMRieYhW0B8=; b=IRwY1BAVwiWJQQixwDsvom3Gqx8QrjepNq76W4GDeDGK5770WPneLPJ65QFbPUdoa+ stXCfHX9odjofobQamB1Yf1bSXl2W8J1GFEImbkIm0vVXZnNGJKU+gko+V2VUFcEY2f+ t+EmUpUDec3yTob/KQPt5vtypVSCjp4CpAEjQtzYNo0YodKDgYCRS7fLNLtteVzLtEvK GiihFUw6q2bofxkRiiewR39zoY/u4oEC+TIss9bD+++tDbeeSZtd9s23MhL8oZhFHZF9 Z4AvD5Fdf6bQ8EjUoCNzR3vTsIaE9wjh26gx89On8V0DBSp8VM/3sDNuHEsrjLPRAyx1 4chg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jv3kh4sN2QHe8ahB8Q2g7jI3TtUGlAvNgMRieYhW0B8=; b=l1oW/MX/th7C8mZQ0uNdoNYqVHqu+XPfFi8Au96GTWkK8syCH7bjWIkcX//A6ZkB4z Wvbit1c17Z+AMzMbyDUd79WZk1hEY/xd+5j5PTp4xlBUrXTePuInRyjKIDJISgGr5VEW qmlfOWlXnIkQkJ/t6/YvcDNGih2EwwLXc6BkeNwgLxNz+MMhgc0t/KosgIKvgGQrqiOR qrmR43YfUuAVOfyAOVUzluMa5zJgiymHUAP31pElErQ34rY/eqhqVQIBrzkBavg1Wz32 lWroRz6sKQJwES+yYWKODYAiiR7ObKKda4s+Tvt0CWUgqKdsGXrPB0LF9qodFAODKU56 U/mg== X-Gm-Message-State: AJIora92y6YVgSQ/vyAEH2oYNBg39b0SxMZHJPOd/5YdAzj7UCgfdM5C JzxJvo2RG8Gh4mm4ca1YZE8= X-Google-Smtp-Source: AGRyM1tPirIUuQlH7GMPyUOzQfzSLrkY/vLj3W9odqlbidIFG4yx38I2EZQfcvx7Zckc0tyRy/vDNg== X-Received: by 2002:a63:68c7:0:b0:405:1da9:ab69 with SMTP id d190-20020a6368c7000000b004051da9ab69mr22054957pgc.233.1658083870208; Sun, 17 Jul 2022 11:51:10 -0700 (PDT) Original-Received: from [192.168.1.2] (cpe-76-168-148-233.socal.res.rr.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id u10-20020a170902e5ca00b0016a4f3ca28bsm7628481plf.274.2022.07.17.11.51.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Jul 2022 11:51:09 -0700 (PDT) In-Reply-To: <83lesrppcs.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:237295 Archived-At: 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 >> 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.