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

[Jim Porter]

On 8/14/2022 12:30 AM, Eli Zaretskii wrote:
> The manual definitely should be clarified in that matter, because:
>
>    d:/gnu/git/emacs/trunk/src $ which format
>    format is a built-in function in ‘C source code’.
>
> To me this says that 'format' is a built-in command, and the manual
> says such commands should be invoked in preference to external
> commands.  The "eshell/" part is not mentioned anywhere.

I'll work on a fix for that. This is a little more complex than 
immediately apparent though, since Eshell also unfortunately uses the 
term "alias" to refer to two kinds of entities:

1) Command abbreviations created by the user using the 'alias' command,
   e.g. "alias ll 'ls -l'". These are sometimes called "command
   aliases", and are implemented in em-alias.el.

2) Lisp functions with names like 'eshell/FOO'. These are sometimes
   called "alias functions", and are implemented in esh-cmd.el. For
   example, see 'eshell-find-alias-function', which checks if
   'eshell/FOO' exists.

It would probably be good to fix all this terminology for once and for all.

> I get the same output, with 2 exceptions:
>
>    . the name of the temporary file is different
>    . instead of a simple string here:
>
>                       (eshell-set-output-handle 1 'overwrite "/tmp/QqPFwo"))
>
>      I get a file name split into several parts, which are then
>      concatenated by eshell-concat:
>
>                      (eshell-set-output-handle 1 'overwrite
>                                                (eshell-extended-glob
>                                                 (eshell-concat nil "c:/DOCUME" "~" 
> "1/Zaretzky/LOCALS" "~" "1/Temp/OIi8Wd")))
>
> Any chance that the "~" parts here somehow get in the way?

It's possible. I think Eshell is trying to ensure that the "~" doesn't 
get parsed as "home directory" here. But it could be doing something 
wrong there. I did also touch 'eshell-concat' not too long ago, so I 
might have broken something there.

> If not, any other thoughts?  My main worry is that there's something
> here specific to how we invoke subprocesses, which you lately changed.

You could try some Eshell commands that don't use subprocesses to see if 
that changes anything. For example, these should only use Lisp functions:

  ;; Should print "first" in the Eshell buffer:
  eshell/echo ${eshell/echo $eshell-in-pipeline-p | eshell/echo}
  eshell/echo ${eshell/echo $eshell-in-pipeline-p | eshell/echo} | 
eshell/echo

  ;; Should open a temp file containing "first" in a new buffer:
  find-file $<eshell/echo $eshell-in-pipeline-p | eshell/echo>
  find-file $<eshell/echo $eshell-in-pipeline-p | eshell/echo> | 
eshell/echo

The "eshell/" prefix probably isn't necessary, but I figured it's worth 
being extra-careful here while diagnosing the issue. I'm particularly 
interested in whether the third and fourth commands work. If they work, 
that would definitely point towards a bug in Eshell's subprocess 
handling; if not, then that would point to a bug in the "$<subcommand>" 
handling.

I also filed bug#57216 to add ERT explainers that will print better 
error messages for most of the Eshell tests. That doesn't address the 
sometimes-vague documentation of the tests, but I'll do that separately.