Can you please post a code snippet that shows exactly how you are reading the file? If it is part of a long program, then write a short program in Go that does the file reading and shows the behavior you wrote about.
Hello, it's me
I was wondering if after all these years you'd like to meet
To go over everything
They say that time's supposed to heal ya
But I ain't done much healing
Hello, can you hear me
I'm in California dreaming about who we used to be
When we were younger and free
I've forgotten how it felt before the world fell at our feet
will output just the last line BUT without the >
I’ve forgotten how it felt before the world fell at our feet
A line ends in \n (MacOS X and Linux) or \r\n (Windows). \r alone was only on old computers from the eighties and early nineties. You should normally not see it in the wild anymore.
And actually the scanner does scan the full content, not only the last “line” as you call it. But since most terminal emulators will simply set the cursor to the beginning of the line when encountering a \r, the next chars will overwrite the prevoius content. Just check it out:
Greetings from line
(You probably need to replace the lineendings manually).
The documentation of bufio.ScanLines does even tell you in regex notation and in a plain english sentence how it wants a line end to look like:
ScanLines is a split function for a Scanner that returns each line of text, stripped of any trailing end-of-line marker. The returned line may be empty. The end-of-line marker is one optional carriage return followed by one mandatory newline. In regular expression notation, it is \r?\n. The last non-empty line of input will be returned even if it has no newline.
It is a “user-error” kind of situation in which generated files contain invalid line ending. What we are discussing here is how Golang behaves in such situations. Note that text editors and Python (I have not yet tried Java) can read such files.