it works nicely under xp,
but it read the last line twice under ubuntu,
who will teach me the way to correct it?
it works nicely under xp,
but it read the last line twice under ubuntu,
who will teach me the way to correct it?
I understand if there are more sterile space, it is going to read double under xp
but I am sure it works nicely under xp,
I think there are difference between xp and ubuntu.
These are last lines in the document:
it read the last line double,
so there are two same pubs revealed in the chart,
the yellow bar is redundant.
Just seems like that:
hmmm. . .not sure.
I'd approach it by reading in every line using a getline() and then splitting it into separate amounts, this way you can clean off any spurious spaces or carriage returns.
I find a hint,
when the file was edited manually,
that this will take place,under linux
Ascii codes denote the following :
These were introduced to restrain the head of a printer.
Chr(13) = carriage return (proceed to the beginning(left) of the lineup)
chr(10) = Line Feed (move down 1 line.)
These denote end of file or end of transmission
Chr(26) = Ctrl- Z
Chr(04)= Ctrl -D
These are relics from Quite old OS and are now obsolete but may nevertheless be found in some files.
Standard windows
file established lineup separation is denoted by chr(13) Chr(10)Technically printer speak.
End of document markers are sometimes still existing in text files on windows files these will probably be chr(26) (Ctrl-Z)
Standard Unix line separation use only chr(10) which presumes coming into the left of the page. This is more logical in non printer appliions (ie disk / memory files) because you may have to insert many tabs or spaces ino the document to maintain the current x position on a new a line.
End of document markers are sometimes still existing in files . . On unix files these wil be Chr(4) (Ctrl-D)
---------------
Fundamentally the difficulty is that the IFS thing isn't detecting the end of document when you would like it to. This will be attributed to additional characters after the final line (these can be any combination of those described previously)
EG :
9 7 31 0 158.596 156.936-Chr(10)
9 7 30 0 158.096 155.299-Chr(10)
9 7 29 0 156.354 153.872-Chr(10)-Chr(4)
9 7 29 0 156.354 153.872(redundant lineup)
in the above case the IFS thing will not detect the end of document because of the additional character chr(4)
The IFS thing may also be coded in such a manner that it will not detect the end of file if a line feed is present on the finished lineup
EG
9 7 31 0 158.596 156.936-Chr(10) -I am not done yet there's another lineup
9 7 30 0 158.096 155.299-Chr(10) -I am not done yet there's another lineup
9 7 29 0 156.354 153.872-Chr(10) -I am not done yet there's another lineup
End of File
Easiest solution(s)
Assess your file with a hex editor to find out what the end of your files seem like to nail down the exact issue
Ensure you move the document (from windows to unix) with the Ascii convention
Strip ALL extraneous chars from the end of the document including the final line feed so that your document (in a hex editor) would look like :
9 7 31 0 158.596 156.936-Chr(10)
9 7 30 0 158.096 155.299-Chr(10)
9 7 29 0 156.354 153.872