bug#57129: 29.0.50; Improve behavior of conditionals in Eshell

[Eli Zaretskii]

> Cc: larsi@gnus.org, 57129@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> Date: Sat, 13 Aug 2022 11:56:20 -0700
> 
> On 8/13/2022 12:01 AM, Eli Zaretskii wrote:
> > One of the tests in esh-var-tests.el failed on MS-Windows; I fixed it,
> > although I'm not sure it's a correct fix, because the Eshell manual
> > seems to say that a built-in implementation of a command should be
> > preferred by default?
> 
> Sorry about that. I think that's the right fix for that case. Maybe it 
> would make sense to set 'eshell-prefer-lisp-functions' to t for most of 
> the Eshell tests to improve reproducibility on various platforms; tests 
> that want an external command can just put a "*" in front of the command 
> name.

But then this fragment from the Eshell manual:

     The command can be either an Elisp function or an external command.
  Eshell looks first for an alias (*note Aliases::) with the same name as
  the command, then a built-in (*note Built-ins::) or a function with the
  same name; if there is no match, it then tries to execute it as an
  external command.

seems to be inaccurate?  Since 'format' exists as a built-in command,
why did Eshell in this case invoke the external command instead?

> I'm surprised that test fails on MS Windows, since it *should* be 
> testing internal Eshell logic that's not platform-specific. Based on the 
> failure, it looks like one of the following commands is returning the 
> wrong value:
> 
>    echo {echo $eshell-in-pipeline-p | echo} | *cat
>    echo ${echo $eshell-in-pipeline-p | echo} | *cat
>    *cat $<echo $eshell-in-pipeline-p | echo> | *cat
> 
> All of these should return 'first'.

The first two do; the last one returns nothing.

> That test is just checking that, 
> when you're in a subcommand ({...}, ${...}, or $<...>), the value of 
> 'eshell-in-pipeline-p' shouldn't be influenced by the pipeline in the 
> "super-command". Some built-in Eshell commands consult 
> 'eshell-in-pipeline-p', and if it had the wrong value, they might do the 
> wrong thing.

So how to investigate this failure further?

> If nothing else, it would probably be helpful to set up ERT explainers 
> so that the error messages are easier to understand. As it is now, 
> they're not very explanatory.

Indeed, more explanations in this and other tests will be most
welcome.

Thanks.