Hi Tom, On Mon, 16 Sept 2024 at 18:33, Tom Rini <tr...@konsulko.com> wrote: > > On Mon, Sep 16, 2024 at 05:42:12PM +0200, Simon Glass wrote: > > Hi Heinrich, > > > > On Thu, 12 Sept 2024 at 08:58, Heinrich Schuchardt <xypron.g...@gmx.de> > > wrote: > > > > > > On 02.09.24 03:18, Simon Glass wrote: > > > > We don't want ANSI characters written in tests since it is a pain to > > > > check the output with ut_assert_nextline() et al. > > > > > > > > Provide a way to tests to request that ANSI characters not be sent. > > > > > > > > Add a proper function comment while we are here, to encourage others. > > > > > > > > Signed-off-by: Simon Glass <s...@chromium.org> > > > > > > > > > This patch was already NAKed in the last version. > > > > > > Please, adjust the test framework if you need filtering. > > > > In what way should it be adjusted? I hope you are not suggesting that > > sandbox should try to filter out ANSI characters in its assertions? > > Well, perhaps the pytest framework should be filtering it out? And > again and to be clear, I can't reliably run these tests on _hardware_ > because of the ANSI characters tripping things up, this is not a > "sandbox" problem.
Honestly, this approach (creating a problem and then dealing with it downstream) is just not the way things should be. As an alternative, I can send a patch to remove the code which blindly sends commands to a terminal which may or may not be there. That would be more correct than what we have today. We can then discuss how to add ANSI back, with due thought to its downstream impact. It's not great that this discussion is still happening on a v5 patch. There has been plenty of opportunity to provide an alternative option. I doubt any exists. Regards, Simon
