> Date: Sun, 4 Oct 2026 09:55:10 +0200 > From: Patrice Dumas <[email protected]> > Cc: [email protected], [email protected], [email protected] > > On Sun, Oct 04, 2026 at 07:34:17AM +0300, Eli Zaretskii wrote: > > > Date: Sat, 3 Oct 2026 23:53:00 +0200 > > > From: Patrice Dumas <[email protected]> > > > > > > On Sat, Oct 03, 2026 at 10:38:01PM +0100, Gavin Smith wrote: > > > > We don't need to support input files with CRLF line endings except > > > > perhaps > > > > on MS-Windows-like platforms, despite the certainty expressed in the > > > > message > > > > you are replying to. It's a unnecessary burden that we are free to > > > > reject. > > > > > > I agree, but I do not think that it is wrong either, and to have the > > > same output for tests on Windows and POSIX platform it would be handy. > > > > I don't think I understand your "but": Gavin was talking about input > > files, whereas you seem to be talking about output. > > 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? > > If we read input in binary mode, then indeed we need to remove CR "by > > hand". > > 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? 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.
