strange cout behaviour

Question

I compiled on Ubuntu a program that was developed for (and works on) Windows. On Ubuntu, I see this code:

string s = values_[9];
cout << s << endl;
cout << s << "x\n";

producing this output:

high
xigh

The expected output for the second line is "highx". I know that the value of values_[9] is originally read from a file (written on Windows). Printing other strings seems to work normally.

What's going on here?

Rundlet

Answer 1

Run the command with its output piped through cat -A. Probably either the value of s, or the output produced by endl is giving you a '\r' character, which typically sends the cursor back to the beginning of the line.

EDIT: On further thought, the stray '\r' is almost certainly in s, not in the output produced by endl. I had thought there might be some funny locale stuff going on, but having s equal to "high\r" explains the symptoms.

EDIT2: If your system doesn't have cat -A (it's a GNU extension), try cat -v or, if you're desperate, od -c.

Clark

+1 (add "But not on Windows, hence the disparate observations.") – Synn

Actually, \r' does send the cursor to the beginning of the line on Windows (depending on where you write it, I suppose, but it works that way in a cmd window). The difference is that Windows uses '"\r\n"' as a line terminator in text files, whereas Unix uses "\n". Well-behaved software probably won't produce isolated '\r' characters on either system. – Clark

OK, but according to the output there is an isolated \r (otherwise the x would be on its own line). – Synn

As I said, "Well-behaved software" and "probably". 8-)} – Clark

OK, but then this is obviously not "well-behaved software" and so the disparate observations must be due to something else! :) – Synn

Oh, I'm with you. The \r could be stripped (read: discarded as part of the line delimiter) during read on Windows, but not under Linux, leaving it isolated at the end of the text. – Synn

And, yes, endl is defined to be a flush followed by \n. On all platforms. – Synn

There's no cat -A on the Mac (Snow Leopard) either. Gotta love the GNU extensions.... – Moreland

@Ray: They try cat -v, or, if you're desperate, od -c. (Or install GNU coreutils if you're so inclined.) – Clark

@Tomalak: I thought it was \n followed by flush. But a '\n' character can be translated when written to a text stream; on Windows, std::cout << "\n" will write a CR and an LF. – Clark

@Keith: Er, yes, that way around. It can be translated by the underlying buffer, but that would only occur on a system that will handle the \r properly! – Synn

@Tomolak: Yes, but it's not uncommon for text files to be copied from Windows to Unix/Linux systems without being translated. That's one of a plethora of possible explanation for how the '\r' got into values_[9]. (Actually, we have no idea where it came from.) – Clark

Answer 2

The string you're printing has a carriage return '\r' in it. What's happening is that you're printing high, then the carriage return, which puts the cursor back on the start of the line. Then, when you print the x, it overwrites the first letter on the line.

You should either remove the carriage return from the source file (e.g. with dos2unix(1) or many other options), or change your code to strip the carriage return after reading the file in.

Griz

Answer 3

What is probably happening, is that there is a \r in values_[9].

Bookish