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

[Jim Porter]

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.

> One of the tests in eshell-tests.el also fails on MS-Windows, but I
> have no idea how to fix it, nor even what are the details of the
> test.  Are the 'echo' commands in that test supposed to be external
> shell commands or internal Eshell commands?  If the former, it could
> be a problem on MS-Windows.

The echo commands should be internal Eshell commands (since there's an 
'eshell/echo' Lisp function, that one should always be preferred by Eshell).

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'. 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.

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.