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: Sun, 14 Aug 2022 14:40:06 -0700
> 
> 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.

Yes, that could well be a source of a lot of confusion.

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

All the 4 commands do what you say they should do.