GNU bug report logs - #69937
29.1; Eshell ${} expansion includes stderr

Previous Next

Package: emacs;

Reported by: Richard Sent <richard <at> freakingpenguin.com>

Date: Fri, 22 Mar 2024 04:27:02 UTC

Severity: normal

Found in version 29.1

Full log


Message #11 received at 69937 <at> debbugs.gnu.org (full text, mbox):

From: Jim Porter <jporterbugs <at> gmail.com>
To: Richard Sent <richard <at> freakingpenguin.com>, 69937 <at> debbugs.gnu.org
Subject: Re: bug#69937: 29.1; Eshell ${} expansion includes stderr
Date: Sat, 23 Mar 2024 12:31:37 -0700
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 $<command> form, since it will 
mis-parse this:

  $<command 2>&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.




This bug report was last modified 1 year and 87 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.