bug#30725: eshell: built-ins do not handle command substitution

[Jim Porter]

On 1/20/2022 5:38 AM, Lars Ingebrigtsen wrote:
> Jim Porter <jporterbugs@gmail.com> writes:
>
> > Oh, right. I'd forgotten about `skip-unless'. Here's a patch with that
> > added. Thanks.
>
> Looks good to me; pushed to Emacs 29.

Drat. I just found bug#12689, which has a wider variety of test cases, 
and saw that I missed a pretty glaring case here:

  echo ${*echo hi}-there

That is, using a subcommand that gets concatenated to a constant string 
to form the argument (or other variations involving concatenation). Both 
before and after my prior fix, that would print "nil-there". With this 
new patch, it prints "hi-there" as expected.

This new patch should be considerably more robust, since it searches 
recursively for any `(eshell-as-subcommand FOO)' forms to check them. 
That way we don't require the command form to look *exactly* one way. I 
used a generator for this, since that's the clearest to my eyes, but I'm 
open to other implementations.

For completeness, this only fixes the first of two issues in bug#12689 
as described by Samer Masterson:

> There are two issues contained in this bug: eshell-plain-command doesn't
> wait for the process to finish before returning, and echo parses output
> from subcommands as lisp objects instead of as args.
The latter case is,

  echo ${*echo -e "foo\nbar"}-baz

which used to print "nil-baz" (or '("foo" "bar")-baz' if you use *echo 
in both spots). With my patch here, it always prints '("foo" 
"bar")-baz', which is at least wrong in a consistent way now. :)

0001-Further-improve-determination-of-when-commands-can-b.patch
Description: Text document