When using "\n" with writeFile(), it gets converted to \r in the output (Windows 7). If this is expected behavior, how do I control it, and where would this behavior be described?
For an example try the following program and open the resulting files in gvim or a hex editor:
var buffer: TaintedString = "\nxxx\nyyy"
writeFile("t1", "TEST" & "\n\n" & buffer)
writeFile("t2", "TEST" & "\x0A\x0A" & buffer)I case this behavior is intended please reconsider: \n isn't \r and shouldn't be turned into it. To abstract such behavior we might use constants analogous to e.g. DirSep.
Dom answered that question already some time ago:
http://forum.nim-lang.org/t/65
Unfortunately the links does not work any more. But module strutils may help indeed.
It works as intended, \n is converted to CR+LF. This feature means Nim doesn't need to distinguish between "text" and "binary" files and so it would be sad to lose it.
\n isn't \r and shouldn't be turned into it.
Yes, but it's "turned" into CR+LF. If you want just LF, use \L, not \n.
Might it be possible/desirable to have special \-escape characters be case-sensitive and make '\n'=='\l', but retain CR+LF translator magic in a newly distinguished "\N"? This would make situations that look the same as other programming languages (like C) act the same and introduce a novel sequence, "\N", for enhanced Nim-only semantics.
(I realize that now '\t' == '\T' and "\n" == "\N", etc. These letter codes are part of literals not identifiers like the usual style-insensitive situation, after all, and I'm really not trying to rekindle that war... :-) ).
Long-term users might have to think more to use the portable-line-ender "\N", but newer users would be less surprised by the '\l' bit since that's the only Nim departure from "common parlance" for old school special chars. It might impact a lot of existing code. Just a thought, really.
See: http://nim-lang.org/manual.html#string-literals
@Araq: Do you mean that Nim can always use binary files because of this feature. Which would normally mean you need to care yourself for the line endings. While in Nim the developer can just use \n to write plattform specific text files automagically this way?
But using text mode means also that incoming data is changed. So does Nim also reads any data from a file which contains \r\n as just \n? Which would be "text" mode?
I have no windows here right now. Can somebody try what happens with this for windows?
proc test(s: string) =
writeFile("t1", s)
let f = readFile("t1")
writeFile("t2", f)
let r = readFile("t2")
echo "Transparent: " & (if f == r: "True" else: "False")
for c in r:
stdout.write ord(c)
stdout.write ' '
stdout.write '\l'
test r"\n\n"
test r"\r\n"
test "\r\n"
test "\n\n"
test "\l\l"
test "\c\c"
test "\c\l"
On my mac I get:
Transparent: True
92 110 92 110
Transparent: True
92 114 92 110
Transparent: True
13 10
Transparent: True
10 10
Transparent: True
10 10
Transparent: True
13 13
Transparent: True
13 10
Do you mean that Nim can always use binary files because of this feature.
That is what the stdlib's IO does, yes.
Which would normally mean you need to care yourself for the line endings. While in Nim the developer can just use n to write plattform specific text files automagically this way?
Well yes.
But using text mode means also that incoming data is changed.
We don't use text mode.
So does Nim also reads any data from a file which contains rn as just n? Which would be "text" mode?
No. There is no "text" mode in Nim, nor any need for it.
For your program on Windows I get:
Transparent: True
92 110 92 110
Transparent: True
92 114 92 110
Transparent: True
13 13 10
Transparent: True
13 10 13 10
Transparent: True
10 10
Transparent: True
13 13
Transparent: True
13 10
@Varriount Thanks! I guess that clears it up. So Nim uses binary mode and converts "n" in string literals to the platform specific line ending at compile time.
Even if not really needed: Can one switch that off?
@Araq I did not mean that Nim uses text mode in any way. I just pointed out that using text mode is not only about writing line-endings but also about reading them. So the strategy in Nim is to handle CR LF transparently (system.nim does this afaik) while text mode on windows changes your data (on read) and leaves only the LF in the data (iirr).