UNIX vs. Windows "\n"

[Anon]

My new web host is on a UNIX box. I had been writing to a flat file lines of data, each terminated with the familiar "\n". But this doesn't work on UNIX. Everything is on one long line, with an unrecognized character at the end of each string. I need to use (according to their help desk) a \r and a linefeed to display this properly on my PC.

Question is, what is the escape code for a linefeed? Would that be "\l"? So would this work like "data\r\l" ?

[antileon]

On Windows, a simple carriage return (CRLF) is \r\n (so CR is \r and LF \n) (ascii code 0x0D, 0x0A = 13, 10)

On UNIX, it's simple \n (0x0A, 10)

[Anon]

I appended a "\r\n" instead of just the "\n" and it works fine, meaning when I view the file on the server, it now contains a new line for each entry.

On another note . . .

I have a list box function that I built in PHP. It reads the list entries from a txt file and builds the list box selections based upon that. This way, no coding changes are necessary if the list ever changes, only the txt file need be modified.

This all works fine until I get to the end of the txt file. I cannot seem to get the function to ignore null lines. I've tried trapping for "", "\r", "\n", "\r\n" but nothing seems to work. It reads the line anyway and screws up the end of the list, putting a blank entry in the list box. The only fix I have found so far is to make sure that the txt file does not contain a CR after the last entry.

This should be an elementary string parsing issue, but it's got me stumped.

Any suggestions?

[kparker]

I appended a "\r\n" instead of just the "\n" and it works fine, meaning
when I view the file on the server, it now contains a new line for each
entry.

On unix, text files most definitely only need \n to terminate the lines. It sounds rather that what's going on here is an html display problem, where html treats any sequence of whitespace characters as a single space. How exactly are you displaying that text file? Perhaps just putting it in a <pre> section will be enough, or else you can use nl2br() before displaying it.

[Anon]

I am simply viewing it online using my FTP client's View button. I use WS_FTP95.

Viewing the local downloaded copy had the same problem until I appended the "\r\n" to each line (on the server side). My new web host has told me that my old web host (Verizon) ran on NT boxes, not UNIX, so that was where the confusion came in.

[kparker]

Ah. So you're moving the file from the unix host to a PC, most likely in binary mode (for some reason that's what WS_FTP defaults to.) First make sure you change the mode to ascii, then try viewing the file and see if it makes a difference.