Hello,
I've got a text file containing 2 lines, forced to use code mode to show the exact content:
\\ciosrv034\status\
30000
I've got the following code:
let argv = commandLineParams()
let contentO = readFile(my_file).split("\n")
var path = contentO[0]
echo contentO # strange the first part ends by \\\c, which is not in the file
echo contentO[0] # seems to be OK
echo argv[1] # seems to be OK
path.add(argv[1])
echo path # should be \\ciosrv034\status\CIOSRV026.csv ?
echo contentO[0] & argv[1] # should be \\ciosrv034\status\CIOSRV026.csv ?
let dest = contentO[0] & argv[1]
echo "writing to " & dest # why CIOSRV026.csvciosrv034\status\ ?
quit(3)
I am calling with "myprog toto.txt CIOSRV026.csv " I've got the output:
@["\\\\ciosrv034\\status\\\c", "30000"]
\\ciosrv034\status\
CIOSRV026.csv
CIOSRV026.csvtatus\
CIOSRV026.csvtatus\
CIOSRV026.csvciosrv034\status\
At first I was using join as with other projects, but I do not understand what I am missing, if somebody could help please?
I am using nim 1.4
OK I will try this, but I've worked a lot with text files under windows and did massive use of
split("\n")
with Windows text files that was #13 #10 ended without any issue, but that was prior to nim 1.4as others have said splitLines will handle windows files better than split
as the docs say: "Every character literal newline combination (CR, LF, CR-LF) is supported. "
split and splitLines have not changed since well before v1.0, i guess you just got lucky before :)
to illustrate:
import strutils
let thingy = "First\r\nSecond\r\nThird"
echo "split \\n:\t", thingy.split('\n')
echo "split Newlines:\t",thingy.split(Newlines)
echo "splitLines:\t",thingy.splitLines()
output:
split \n: @["First\c", "Second\c", "Third"]
split Newlines: @["First", "", "Second", "", "Third"]
splitLines: @["First", "Second", "Third"]
I've worked a lot with text files under windows and did massive use of split("n")
That's either because old versions of Nim transformed \n to \c\L on Windows (\p now has this behavior), or because you previously weren't using anything that would point out the problem. I'm guessing you were using powershell, in powershell carriage return sets the cursor to the start of the current line and overwrites it, which explains the output.
The crucial thing to realize about the carriage return is that it affected the way your terminal displayed the text, not its internal representation. Its behaviour doesn't even have anything to do with what shell you use, but which terminal emulator! For me, in a shell, if I
echo 'applesauce\roranges\n`
I get orangesuce
Because, as @PMunch pointed out, the carriage return character is an instruction to the terminal to do something weird.
heres some more on the subject