When do I use the PHP constant "PHP_EOL"?

Question

When is it a good idea to use PHP_EOL? I sometimes see this in code samples of PHP. Does this handle DOS/Mac/Unix endline issues? Most of the PHP I write is for generating HTML, and I use <br/> instead of actual newlines, so haven't used this constant before.

Answer 1

Yes, PHP_EOL is ostensibly used to find the newline character in a cross-platform-compatible way, so it handles DOS/Mac/Unix issues.

Answer 2

You use PHP_EOL when you want a new line, and you want to be cross-platform.

This could be when you are writing files to the filesystem (logs, exports, other).

You could use it if you want your generated HTML to be readable. So you might follow your <br> with a PHP_EOL.

You would use it if you where running php as a script from cron and you needed to output something and have it be formated for a screen.

You might use it if you where building up anemail to send that needed some formatting.

Answer 3

I'm using PHP _EOL when building the message body of my email but the line feeds are not getting through and the entire message body ends up one long line.... Any ideas?

Answer 4

Use it when you need it. Otherwise don't. :) I can't say that I have ever used it myself.

Answer 5

The definition of PHP_EOL is that it gives you the newline character of the operating system you're working on.

In practice, you should almost never need this. Consider a few cases:

• When you are outputting to the web, there really isn't any convention except that you should be consistent. Since most servers are Unixy, you'll want to use a "\n" anyway.

• If you're outputting to a file, PHP_EOL might seem like a good idea. However, you can get a similar effect by having a literal newline inside your file, and this will help you out if you're trying to run some CRLF formatted files on Unix without clobbering existing newlines (as a guy with a dual-boot system, I can say that I prefer the latter behavior)

PHP_EOL is so ridiculously long that it's really not worth using it.

Answer 6

Handy with error_log() if you're outputting multiple lines.

I've found a lot of debug statements look weird on my windows install since the developers have assumed unix endings when breaking up strings.

Answer 7

I use the PHP_EOL constant in some command line scripts I had to write. I develop on my local Windows machine and then test on a Linux server box. Using the constant meant I didn't have to worry about using the correct line ending for each of the different platforms.

Answer 8

I am using WebCalendar and found that Mac iCal barfs on importing a generated ics file because the end-of-line is hardcoded in xcal.php as "\r\n". I went in and replaced all occurrences with PHP_EOL and now iCal is happy! I also tested it on Vista and Outlook was able to import the file as well, even though the end of line character is "\n".

Answer 9

I prefer to use \n\r. Also I am on a windows system and \n works just fine in my experience.

Since PHP_EOL does not work with regular expressions, and these are the most useful way of dealing with text, then I really never used it or needed to.

Answer 10

When jumi (joomla plugin for PHP) compiles your code for some reason it removes all backslashes from your code. Such that something like $csv_output .= "\n"; becomes $csv_output .= "n"; Very annoying bug! Use PHP_EOL instead to get the result you were after.

Answer 11

I found PHP_EOL very useful while file handling specially if you are writing some content into a file to move into the new line.

For example, you have a long string that you want to break into the multiple lines while writing into plain file. Using \n\r might not work so simply put PHP_EOL into your script and the result is awesome.

Check out this simple example below:

<?php

$output = 'This is line 1' . PHP_EOL .
          'This is line 2' . PHP_EOL .
          'This is line 3';

$file = "filename.txt";

if (is_writable($file)) {
    // In our example we're opening $file in append mode.
    // The file pointer is at the bottom of the file hence
    // that's where $output will go when we fwrite() it.
    if (!$handle = fopen($file, 'a')) {
         echo "Cannot open file ($file)";
         exit;
    }
    // Write $output to our opened file.
    if (fwrite($handle, $output) === FALSE) {
        echo "Cannot write to file ($file)";
        exit;
    }
    echo "Success, content ($output) wrote to file ($file)";
    fclose($handle);
} else {
    echo "The file $file is not writable";
}

?>