Accurate wording is important.

We both agree that "\n" prints something different under Unix than on Windows.

No. What gets written to a handle by a print "\n" can be the same on both platforms, or different, depending on which I/O layers are in effect.

I further claim that all network communication uses <CR><LF> as the transmitted line ending. You do not believe that.

No, I didn't say that either. You claimed that "no matter what the OS platform, when writing to a network socket, "\n" means <CR><LF>", which I proved to be incorrect. This is completely separate from the fact that many network protocols do indeed use CRLF as their standard line ending (Update: and certainly not "all" network protocols use CRLF).

I am curious what these nulls mean? "foo\n\0"\0

I added the \0s for two reasons: the server is hard-coded to expect five bytes, and I wanted to make sure that the client always sends at least that many bytes, second, I wanted it to be clear that the server isn't reading too few bytes and cutting off something relevant. The \0 after the quote is AFAIK Perl's way of saying the string is null-terminated (ASCIIZ).

No. What gets written to a handle by a print "\n" can be the same on both platforms, or different, depending on which I/O layers are in effect.

I don't have any quibble about that. I was just talking about what Perl will do by default on various platforms. Perl is one of the most amazingly configurable languages that I've ever worked with. If it normally "barks" and you want it to "meow", it can do that!

As far as network sockets go, I need to gain access to a Unix machine for testing. Again we are talking about default print statements of strings without any special I/O layer being specified or writing binary to the socket.

I think that it is fair to say that this whole line ending subject is complicated. There are a lot of "yeah but's".

As far as network sockets go, I need to gain access to a Unix machine for testing.

I use VirtualBox. But in this case, I already ran my tests on both OSes - I even highlighted that.

I believe that the confusion here is that the standards specify use of <CR><LF> (as far back as RFC139, page 3, on a quick check) but *nix has a far simpler I/O model than was contemplated for the systems on the early ARPAnet. (ASCII itself is RFC20, by the way.)

So for correct and portable network usage, you are supposed to use "\015\012" rather than "\n" anyway, although Perl's ":crlf" PerlIO layer should cause "\n" to be emitted as "\015\012". Confused enough yet?

Thank you for the RFC reference.
I believe that you are correct and that Perl's default text I/O layer will do what you say.
I currently don't have a UNIX system to test with, but yes, this is "the way it is supposed to work".

I someone is writing both ends of a client/server application, of course you can do whatever you want.You can even just send a binary packet.

Note that on *nix, the "default text I/O layer" is probably effectively :raw and :crlf is not used unless requested, because the Unix convention is that text files store only <LF> at end-of-line and "\n" is <LF> in POSIX.

And the reason that you are supposed to specifically say "\015\012" instead of "\r\n" is that the latter is the current platform's notion of "carriage return/line feed" and might not be the ASCII CR/ASCII LF that is supposed to be used on the network. (I seem to recall that classic MacOS interpreted "\r\n" as "\012\015" as one example. I suspect EBCDIC systems may be even more bizarre.)

Edited 2019-10-01 by jcb: Clarify wording to address haukex's nitpick.