Subject: Re: bug#79030: rare failure of esh-cmd-test/reset-in-pipeline/subcommand

From: Jim Porter <[email-masked]>
Date: Wed, 16 Jul 2025 09:45:14 -0700

On 7/16/2025 5:04 AM, Eli Zaretskii wrote:
>> Date: Tue, 15 Jul 2025 23:50:13 -0700
>> From: Paul Eggert <[email-masked]>
>>
>> On the master branch, on Ubuntu 25.04 x86-64, I ran "make -j12 check"
>> about 130 times in sequence, and eventually got a failure in
>> esh-cmd-test/reset-in-pipeline/subcommand. The problem is most likely
>> timing related. The rest of this email is a copy of the failed
>> esh-cmd-tests.log.
> 
> Thanks.
> 
> Jim, any ideas or suggestions?

What's interesting here is that the actual output is correct, except 
that it has an extraneous newline:

>       (nonequal-result
>        (command "*cat $<echo | echo $eshell-in-pipeline-p | echo> | *cat")
>        (result "t\n") (expected "t")))) 

This test case is testing what happens in some relatively-complex 
pipeline, where we redirect the inner $<...> command to a temp file, and 
then the first cat reads that file, piping it to a second cat. The inner 
command is just making sure that we set the internal 
$eshell-in-pipeline-p variable correctly (it should be 't' here). By 
default, Eshell echo doesn't emit a newline (for complicated reasons).

So, it's something like this in a regular shell:

   echo -n t > /tmp/something
   cat /tmp/something | cat

Based on the logs, I think what's happening is that the $<...> is adding 
a trailing newline to the temp file. I don't know why that's happening 
though, especially not randomly. My guess is that somehow the buffer for 
the temp file changed away from 'fundamental-mode' to some text mode. 
You can see something like this happen if you run the Eshell command 
above, then retry it with 'major-mode' set to 'text-mode'; it'll add a 
newline in the latter case.