On Sun, Oct 04, 2026 at 11:06:33AM +0300, Eli Zaretskii wrote: > > Date: Sun, 4 Oct 2026 09:55:10 +0200 > > From: Patrice Dumas <[email protected]> > > No, I am talking about input files. In the tests, there is a file with > > a CRLF because there is an explicit CR at the end of the line. > > tta/perl/t/input_files/only_special_spaces_node.texi > > Currently, the CR is removed on Windows with text I/O, while > > on GNU/Linux, the CR is left. This leads to a different tree (and > > probably different output). > > Why is there a CR there? What does it signify or what real-life > situation it wants to test?
Many tests, especially in the tta/perlt/*.t do not test for real-life situations. These are unit-tests which purpose is to: * test corner cases and unexpected situations * try to cover all the code, even the code triggered by very unusual situations (in particular situations that cannot arise with input files) * allow being confident that there are no regressions when the code is modified/rewritten These three objectives are intertwinned and synergistic. Some of those unit tests also test for real-life situations. There are more real-life situation tests in the tta/tests test suite, although there too, some tests are for unusual situations. That being said, for this specific case, we have one real life situation, which is a Texinfo manual created on Windows and converted to an output format on GNU/Linux or similar. And one semi-real life situation, which would be adding tests with input Texinfo manuals with CRLF in the texi2any test suite, which become relevant if we routinely test on mingw platforms in the CI, as we now do. > > We may not need to do it in general, but we need to do it if we want to > > have CRLF treated the same on GNU/Linux and Windows, by removing CR in > > both cases. > > What is the reason for supporting CRLF files on Posix systems, given > that Gavin doesn't like it too much? For tests. And secondarily, to have correct output if input Texinfo manual has CRLF, although I agree that this second reason is not a strong reason. > In general, removing CRs is not rocket science, but one should be > careful not to remove them except when they are followed by an LF. What I would do is * open the file in binary mode * remove/replace a CR before a LF at the end of th estring upon reading. -- Pat
