@SitiSchu I am not sure whether I want to support this: parsing the output of curl is a very specific use case, and you can already do that with

curl ... | splits "\r\n" (slurp)

I think this has less to do with supporting the output of curl and more to do with doing the right thing on MS Windows.

P.S., I despise MS Windows because of its numerous shortcomings. Not least of which is using \r\n for line endings solely because doing so meant you could cat a plain text file to a printer device and have it do the "right thing" more than four decades ago. Without any alteration of the text by the operating system. In other words, the \r\n was chosen as a line ending because each character in that pair would cause a dumb printer to do the "right thing" in terms of rendering the plain text.

You can find a lot of legacy stuff in UNIX that no longer makes sense today too :)

Also, I need to check that pipes in Windows actually use \r\n as line endings. With C on Windows, you have the distinction between "text mode" and "binary mode"; in text mode, you can pretend that the line ending is \n and stdio does the conversion for you. I am not sure if that applies to Go.

Oh yeah, native Windows commands do use \r\n as the line ending when invoked from the console. In the spirit of doing the correct thing, Elvish should support \r\n as a separator for implicit splitting in output capture expressions.

This behavior should be adopted everywhere. This has the nice side effect of making it easier to parse the output of curl and (even more rarely) working with files with CRLF line endings on Unix, but as @krader1961 said this is more about doing the correct thing on Windows.

Code that really cares about the exact bytes can always use slurp to turn the entire byte output to a string in a lossless way.

Tangent to this issue:

Interestingly enough, a lone \n also works perfectly in the console (at least in a recent version of Windows 10); Go manages to get away with fmt.Println only writing a \n on Windows, which is perfectly fine when used interactively, and the only downside seems to be that if the output is saved in a file you get LF line endings instead of CRLF (golang/go#28822).

This is a backward-incompatible change, but since it's so rare for Unix commands to write \r this change will be introduced directly.

Yeah, for plain text files the only time you're likely to see \r\n line endings on a UNIX platform is if the file a) originated on a Windows systems, or b) it's mandated by something like the HTTP standard. And when dealing with binary (non-plain text) files on UNIX you shouldn't be using or relying on functions that read "lines". So I agree that changing the behavior is low risk.