GNU bug report logs -
#79030
rare failure of esh-cmd-test/reset-in-pipeline/subcommand
Previous Next
Full log
Message #11 received at 79030 <at> debbugs.gnu.org (full text, mbox):
On 7/16/2025 5:04 AM, Eli Zaretskii wrote:
>> Date: Tue, 15 Jul 2025 23:50:13 -0700
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>>
>> 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.
This bug report was last modified 66 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.