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

[Jim Porter <jporterbugs@gmail.com>]

On 8/15/2022 5:13 AM, Eli Zaretskii wrote:
>> Cc: larsi@gnus.org, 57129@debbugs.gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>> Date: Sun, 14 Aug 2022 14:40:06 -0700
>>
>> 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.

Hm, and I can't reproduce this on the prebuilt Emacs 29 snapshot from 
July 18, which is from just before I merged the changes to 
'make-process', so it's definitely possible that this is due to those 
commits.

Does reverting 4e59830bc0ab17cdbd85748b133c97837bed99e3 and 
d7b89ea4077d4fe677ba0577245328819ee79cdc fix the issue? I checked 
locally, and they should revert cleanly at least.

It might also be interesting to revert just the changes from d7b89ea in 
lisp/eshell/esh-proc.el. I don't think any of the changes I made to the 
C sources should impact this, since a) I was careful to keep the logic 
as close to before as I could, and b) it just changes the logic for 
creating a PTY, which doesn't work on MS Windows anyway.

I did notice one weird issue though, and maybe this has something to do 
with the problem: on MS Windows, if I run any command with a 
$<subcommand>, the second and subsequent times, it warns me about 
changing the temp file, e.g.:

   3Zz80A has changed since visited or saved.  Save anyway? (yes or no)

This probably shouldn't do that, and it could definitely cause issues in 
the tests, which can't prompt the user for things like that.