GNU bug report logs -
#60942
30.0.50; [PATCH] Indices in Eshell variable interpolation don't work with async subcommands
Previous Next
Reported by: Jim Porter <jporterbugs <at> gmail.com>
Date: Thu, 19 Jan 2023 03:37:02 UTC
Severity: normal
Tags: patch
Found in version 30.0.50
Done: Jim Porter <jporterbugs <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Thu, 19 Jan 2023 17:54:01 -0800
with message-id <3bed595c-6f7e-5049-2c8d-bee83d13c3e8 <at> gmail.com>
and subject line Re: bug#60942: 30.0.50; [PATCH] Indices in Eshell variable interpolation don't work with async subcommands
has caused the debbugs.gnu.org bug report #60942,
regarding 30.0.50; [PATCH] Indices in Eshell variable interpolation don't work with async subcommands
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
60942: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60942
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
Starting from "emacs -Q -f eshell":
~ $ echo $exec-path[0]
/usr/local/sbin
~ $ echo $exec-path[${echo 0}]
/usr/local/sbin
~ $ echo $exec-path[${*echo 0}]
;; no output
This is because 'eshell-eval-indices' gets an S-expr describing code to
evaluate for the indices, and it just passes that to 'eval'. That's not
the right way to do things for Eshell: instead, we should rely on
'eshell-do-eval', which properly handles asynchronous evaluation. That's
required for working with external commands like "*echo" (which calls
the real /bin/echo).
The attached patch fixes this by changing 'eshell-eval-indices' to
'eshell-indices', which does some minimal transformations on the S-expr
for the indices, and then uses it to build the final S-expr to pass to
'eshell-do-eval'.
This could possibly go in Emacs 29, since it's a bugfix to add onto a
previous bugfix (see commit 990f36fa10). However, I'd lean towards just
merging to master; this is a fairly obscure issue, and we can't just fix
*every* bug we find on the release branch, or the branch will never
stabilize. If someone else thinks it's important enough to go on the
release branch though, I won't argue.
[0001-Fix-evaluation-of-asynchronous-expansions-in-Eshell-.patch (text/plain, attachment)]
[Message part 5 (message/rfc822, inline)]
On 1/19/2023 12:20 PM, Jim Porter wrote:
> On 1/19/2023 11:41 AM, Eli Zaretskii wrote:
>> Is this for master? If so, okay. Otherwise, you'll need to adjust
>> the version in the obsolescence declaration.
>
> Personally, I think just for master. The change isn't entirely
> risk-free. This code is a bit tricky, and I'd want a fair amount of time
> for people to identify bugs, just in case I regressed something.
And now merged to master as 54d5ea66c9. Closing this bug.
This bug report was last modified 2 years and 123 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.