Hi brian, On Fri, 22 Jan 2021, brian m. carlson wrote: > On 2021-01-22 at 16:29:46, Johannes Schindelin wrote: > > > > 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. If we needed another reminder that we never say "It's in POSIX; we'll happily ignore your needs should your system not conform to it." (https://github.com/git/git/blob/v2.30.0/Documentation/CodingGuidelines), then we have it right here ;-) > > 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. I have two comments on that: 1. We could spend a splendid time questioning MSYS2's (and before that, MSys') choices regarding newlines, but I think we can spend that time a lot better. 2. Newer software _seems_ to handle LF line endings just fine. And the `sed` invocation you mentioned above does so: it groks input delimited by Line Feed as newline characters. That does not mean that its output is LF-only by default. I seem to remember that recent Visual Studio versions did something similar: happily read an LF-only `.xml` file, but then write out a modified version using CR/LF. Would I wish that Windows used LF-only instead of CR/LF, just like macOS switched away from CR-only to LF-only after MacOS 9? Sure I do. It would remove quite a few obstacles in my daily work. Can I do anything about it? No. So I'd rather see `git mergetool` be turned into a portable C program, or alternatively using a built-in helper that _is_ written in C, to perform that desired text munging instead of losing the battle to the challenge of cross-platform, advanced text processing in pure shell script. Ciao, Dscho
