<CR> issues - Windows hell! =)

[Anon]

This problem involves Carriage Return <CR> translation issues between Windows and Linux.

I wrote some PHP code (running on Linux) using fscanf() to scan a tab-delimited text file and then do stuff with the scanned content. The format is similar to this: %s\t%s\n.

The code works really great when the tab-delimited file is created using Linux, Unix or even Mac text editors. BUT, since most people use Windows, I needed to make sure a tab-delimited text file created on Windows (using Excel or Word in particular) would work. Well, it doesn't. Surprise, surprise! ;-)

The problem is, the format used in fscanf() does not recognize the Windows carriage return. After some research I learned that Linux/Unix/Mac use \n for <CR>. Windows apparently uses a ^M, which is equivalent to \r.

So I try \r instead in the format, BUT, \r is not recognized either! I even tried \f. =)

I opened the Windows text file in pico and pico sees the Windows carriage return as a ^M (Control-M). Obviously, the PHP code is also seeing the ^M and doesn't recognize it as \r, and the fscan just terminates thinking it is done, making the script useless.

The question is, how the hell do I make Linux understand that the Windows carriage return (^M) is \n , \r?

Or is there some work-around?

Thank you in advance. Chris.

[vsego]

I'd use fgets() to get the line, then chop() to remove new-line, whatever kind they were. It always works.

[Anon]

I think Windows newlines are "\r\n".

-JoshB

[Anon]

The problem is directly related to how Excel and Word save tab-delimited files. There must be something screwy going on.

I discovered the fix is not to save files as 'tab-delimited' files, but as 'text only' files. fsacnf() and fgets() recognize \n, \r now.