On 2021-01-22 at 16:29:46, Johannes Schindelin wrote: > Hi brian, > > On Fri, 22 Jan 2021, brian m. carlson wrote: > > > On 2021-01-16 at 04:24:54, Seth House wrote: > > > The autocrlf test is breaking because the sed that ships with some mingw > > > versions (and also some minsys and cygwin versions) will *automatically* > > > remove carriage returns: > > > > > > $ printf 'foo\r\nbar\r\n' | sed -e '/bar/d' | cat -A > > > foo$ > > > > > > $ printf 'foo\r\nbar\r\n' | sed -b -e '/bar/d' | cat -A > > > foo^M$ > > > > > > (Note: the -b flag above is just for comparison. We can't use it here. > > > It's not in POSIX and is not present in sed for busybox or OSX.) > > > > Can you report this as a bug? This behavior isn't compliant with POSIX > > and it makes it really hard for folks to write portable code if these > > versions implement POSIX utilities in a nonstandard way. As a > > non-Windows user, I have no hope of writing code that works on Windows > > if we can't rely on our standard utilities working properly. > > I fear that the Windows-based tools do the correct thing, though: they are > meant to process _text_, and newlines are supposed to be > platform-dependent in text. Ah, but POSIX gives a very specific meaning to "newline", and it refers to a single byte. If you want tools that process CRLF line endings like that, then that should be opt-in as either different tools or additional options, not the default behavior of a POSIX tool. This behavior is not conforming to POSIX and it is therefore a defect. > From that perspective, it sounds to me as if we're trying to ask `sed` to > do something it was not designed to do: binary editing. Most Windows tools are perfectly capable of handling LF line endings. Even the famously incapable Notepad can now handle LF without CR. With the advent of WSL, handling LF line endings is now pretty much required. -- brian m. carlson (he/him or they/them) Houston, Texas, US
Attachment:
signature.asc
Description: PGP signature
