Daniel Bump bump@match.Stanford.EDU writes:

So it is worth reviewing how GNU Go 2.7.253 handles the newlines in the GTP.

Newlines are written in gtp.c and play_gtp.c with the standard C function printf(" ... \n"). On Unix this makes a LF=\012. On DOS it makes CRLF. David stated that on Macintosh it makes just a Carriage return but we believe this is not true with OS X. If it were, things would be worse broke than they are now.

(Does anyone know?)

FWIW... just discovered that the perlport man page has some discussion on this :

ISSUES Newlines

In most operating systems, lines in files are terminated by newlines. Just what is used as a newline may vary from OS to OS. Unix traditionally uses \012, one kind of Windows I/O uses \015\012, and Mac OS uses \015.

Perl uses \n to represent the "logical" newline, where what is logical may depend on the platform in use. In MacPerl, \n always means \015. In DOSish perls, \n usually means \012, but when accessing a file in "text" mode, STDIO translates it to (or from) \015\012.

Due to the "text" mode translation, DOSish perls have limitations of using seek and tell when a file is being accessed in "text" mode. Specifically, if you stick to seek-ing to locations you got from tell (and no others), you are usually free to use seek and tell even in "text" mode. In general, using seek or tell or other file operations that count bytes instead of characters, without considering the length of \n, may be non-portable. If you use binmode on a file, however, you can usually use seek and tell with arbitrary values quite safely.

A common misconception in socket programming is that \n eq \012 everywhere. When using protocols such as common Internet protocols, \012 and \015 are called for specifically, and the values of the logical \n and \r (carriage return) are not reliable.

print SOCKET "Hi there, client!\r\n"; # WRONG print SOCKET "Hi there, client!\015\012"; # RIGHT

[NOTE: this does not necessarily apply to communications that are filtered by another program or module before sending to the socket; the the most popular EBCDIC webserver, for instance, accepts \r\n, which translates those characters, along with all other characters in text streams, from EBCDIC to ASCII.]

However, using \015\012 (or \cM\cJ, or \x0D\x0A) can be tedious and unsightly, as well as confusing to those maintaining the code. As such, the Socket module supplies the Right Thing for those who want it.

use Socket qw(:DEFAULT :crlf); print SOCKET "Hi there, client!$CRLF" # RIGHT

When reading from a socket, remember that the default input record separator ($/) is \n, but code like this should recognize $/ as \012 or \015\012:

while (<SOCKET>) { # ... }

Better:

use Socket qw(:DEFAULT :crlf); local($/) = LF; # not needed if $/ is already \012

while (<SOCKET>) { s/$CR?$LF/\n/; # not sure if socket uses LF or CRLF, OK # s/\015?\012/\n/; # same thing }

And this example is actually better than the previous one even for Unix platforms, because now any \015's (\cM's) are stripped out (and there was much rejoicing).

An important thing to remember is that functions that return data should translate newlines when appropriate.

Often one line of code will suffice:

$data =~ s/\015?\012/\n/g; return $data;

dd