GNU bug report logs - #60942
30.0.50; [PATCH] Indices in Eshell variable interpolation don't work with async subcommands

Previous Next

Package: emacs;

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


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: 60942 <at> debbugs.gnu.org
Subject: Re: bug#60942: 30.0.50;
 [PATCH] Indices in Eshell variable interpolation don't work with
 async subcommands
Date: Thu, 19 Jan 2023 08:49:34 +0200
> Date: Wed, 18 Jan 2023 19:36:41 -0800
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> 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.

Why do you remove a non-internal function?  We cannot possibly do that
if this is going to be installed on the emacs-29 branch.  But even if
you are going to install on master, why not leave that function alone?
Some code somewhere could be using it, and we don't usually remove
functions before a period of deprecation.




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.