Daniel Bump bump@match.Stanford.EDU writes:
I'm cc'ing both the GNU Go list and the GTP list because this is a protocol issue.
To summarize, Trevor Morris reports that the GNU Go regressions are broke on Visual C. The reason is that apparently printf on VC++ interprets \n as CRLF instead of just LF.
AFAIK VC is doing the correct thing : \n is defined to expand to whatever line ending is appropriate for the platform.
[ I would be inclined to blame the awk for not understanding CRLF when reading in text on a dos-like machine. Possibly a feature of cygwin tools, since someone at work here had similar problems which turned out to be do with the tools not processing CR as I would have expected them to. ]
I think I did mention this feature of \n | \r, and pointed out that any portable implementations of GTP code should use \012 explicitly if they mean a LF character.
I think this is an issue which was discussed in the protocol list but I do not remember whether any conclusions were reached.
Trevor Morris wrote:
Do you mean that the gtp output is getting spurious CR's added by the DOS version of the program?
Yes, this is the problem. Spurious CR added by the DOS version of the program. An appropriate sed script to strip out the offending ^M characters should do it.
Perhaps the GTP needs to explicitly define what the end-of-line character(s) should be?
We can simulate this problem on Linux by replacing all occurrences of \n by \r\n in gtp.c. I just did that and found that regress.sh is broke but twogtp is not.
That wouldn't help since on windows that would (may) give CRCRLF
And on mac, \n is CR
\012 is probably safest if you really mean a LF character
One difference between the two is that regress.sh is awkward where twogtp is perlward. Perhaps we should reimplement regress.sh in perl.
FWIW, the regress script doesn't work properly with /usr/bin/awk on solaris. Need to use nawk instead. perl is probably slightly better defined, and therefore more portable.
dd