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#69937: 29.1; Eshell ${} expansion includes stderr Date: Sat, 23 Mar 2024 12:31:37 -0700 Message-ID: <0a81134a-8abe-3f20-47cb-e57fe8524a84@gmail.com> References: <87v85ej3sx.fsf@freakingpenguin.com> 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="30082"; mail-complaints-to="usenet@ciao.gmane.io" To: Richard Sent , 69937@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 23 20:39:38 2024 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 1ro7DN-0007cB-QA for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 23 Mar 2024 20:39:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ro7D9-0006fV-FY; Sat, 23 Mar 2024 15:39:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ro7D7-0006ey-M3 for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2024 15:39:21 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ro7D7-0004Bi-C7 for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2024 15:39:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ro7Dm-0000Eg-CM for bug-gnu-emacs@gnu.org; Sat, 23 Mar 2024 15:40: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: Sat, 23 Mar 2024 19:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69937 X-GNU-PR-Package: emacs Original-Received: via spool by 69937-submit@debbugs.gnu.org id=B69937.1711222772836 (code B ref 69937); Sat, 23 Mar 2024 19:40:02 +0000 Original-Received: (at 69937) by debbugs.gnu.org; 23 Mar 2024 19:39:32 +0000 Original-Received: from localhost ([127.0.0.1]:49648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ro7DI-0000DP-BE for submit@debbugs.gnu.org; Sat, 23 Mar 2024 15:39:32 -0400 Original-Received: from mail-oi1-f173.google.com ([209.85.167.173]:57526) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ro7DF-0000D7-OL for 69937@debbugs.gnu.org; Sat, 23 Mar 2024 15:39:30 -0400 Original-Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-3c39177fea4so2153807b6e.2 for <69937@debbugs.gnu.org>; Sat, 23 Mar 2024 12:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711222662; x=1711827462; darn=debbugs.gnu.org; h=content-transfer-encoding:in-reply-to:references:to:from :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=5gOroAj+I5+CR89Q42xxyPoijeeBb0ZDZJJ9hltf+Tw=; b=Z81JQq+hxqggE+BWHGJF42OEJOI+XNI9hd8JQmLP4B5lD1XFTtfkLx62IC/8KvAXEw UvYZcLEAKCHfmevUC6cuseMSbd6nKLGIZf6fIfRS0VhSYq28hEXUX0gCWllkOpvwAcox d3H+7UbCZeA1kO703gGzbkqcFO4oyVWMi1R5wGpZ+71w2Dc7EK67jm5KUvM3RU5CwdVv XMY6Uw3tLQPtekD3MWZtAcV+EhKgd5xZuLSze/22AdONiofFl7lOfpkmCLRX1xn2s2hM B4ZjTT8RNtXEdsc1m/mHtqtPHGhzcgVGRRhGHESFOK04aul2M6bc3gA13FdOlTNeET06 lDoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711222662; x=1711827462; h=content-transfer-encoding:in-reply-to:references:to:from :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5gOroAj+I5+CR89Q42xxyPoijeeBb0ZDZJJ9hltf+Tw=; b=dG14T81LtLCEyZsfXvvZ1844crl+BVyHkUWoZubPjRZ94s17iBmB3mwVRSyreqdfPc P1UxU3BVDbrmIqDQRVe3yAwpk71/xxUIY/mdRO8jKUPyiA8cVPwkqV1jIA3l97Yyl5Jr Qd+kx/1LtwhmZTAK5PdckGrsaV/vzP0NKVL+wfZMfa3cBTMcMQlg1o77ZXSrXTkt0h22 2gflVHfylw7PK2BmNsFrtHgIAd6bceXg4RbdNgXoIPf+TEX6MmCAe02UW3j92IACUUoT 2edCI7Sh9ygcSlcoLVe9EJH9DuFp1wNjT3oii0LHPHhK6CAsUWH25VnK8GkfFCYmKfjL aqsg== X-Forwarded-Encrypted: i=1; AJvYcCUtv6jC9CAAFimvE0702wWo7dRCQrKko+1i1Q2fr4GwTEntbwN1quOyRe+4M7qmvH9sJazrvq8orYBs+too8BcLHsB7PgI= X-Gm-Message-State: AOJu0Yytw0HpCu09Wp0m0CnG8VlYwTYzgIoDYE/ikNe/pkVAmo1P1ANH VnXvK8hgzGumOTNz9k6HGiK1Edlr1CDyBmBS8xmDX+FV0CoFu+7/m6LUx7Kj X-Google-Smtp-Source: AGHT+IE5snHpwb2rTeZXFoXhFV22JB8q5SuoUJw8Ea7PAmUKAJWOqlF4LnuVjWsacxC9+Q6/o+XyYw== X-Received: by 2002:a17:903:40c3:b0:1e0:a326:e89e with SMTP id t3-20020a17090340c300b001e0a326e89emr2834685pld.37.1711222298562; Sat, 23 Mar 2024 12:31:38 -0700 (PDT) Original-Received: from [192.168.1.2] (076-168-148-233.res.spectrum.com. [76.168.148.233]) by smtp.googlemail.com with ESMTPSA id l15-20020a170903244f00b001e014627baasm1898490pls.79.2024.03.23.12.31.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Mar 2024 12:31:38 -0700 (PDT) Content-Language: en-US In-Reply-To: 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:281999 Archived-At: On 3/21/2024 10:56 PM, Jim Porter wrote: > I'll try and put together a patch for this over the weekend. I looked into this some more and found that it's not quite so easy to do this in a way that preserves functionality. Normally, you should be able to use the "2>&1" syntax to redirect (and thus capture) *all* the output. However, that fails for the $ form, since it will mis-parse this: $&1> Escaping the inner ">" won't work, since the parser doesn't unescape that character. Unescaping that would be tricky to get anyway, so I'm not sure it's the best route. Another hypothetical syntax would be (whitespace just for readability): $< { command 2>&1 } > That *also* doesn't work today, but reworking 'eshell-find-delimiter' should make that possible, and likely fix some other surprising cases in the Eshell syntax. I have some ideas for how to do this, but it's a pretty invasive change, so it'll take quite a bit of thought. I don't have time to do this right now, but I'll take a look in the coming month or so. Thankfully, aside from this wrinkle, all the *other* parts to fix this bug are pretty straightforward, and in fact I already have a WIP patch for them.