PHP problems when transfering code from Windows to OS X

Question

I have recently bought a new MacBook Pro. Before I had my MacBook Pro I was working on a website on my desktop computer. And now I want to transfer this code to my new MacBo

Answer 1

Check if there are spaces in front of your php opening tag. Also try resaving the file from notepad++ using the windows (crlr) line endings. (Edit > EOL Conversion > Windows format)

Answer 2

Noteworthy is that the error always says that the output is started at line 1. Which got me thinking if there is some kind of coding differences in the way that the Mac OS X and Windows operating systems handle new lines or white spaces? Or could the Dropbox transfer messed something up?

Don’t redo your code or worry about the header() calls or even the cookie stuff. That is not the issue.

The issue is that Windows line endings are different from Mac line endings. More details here.

Different operating systems use different characters to mark the end of line:

• Unix / Linux / OS X uses LF (line feed, '\n', 0x0A)
• Macs prior to OS X use CR (carriage return, '\r', 0x0D)
• Windows / DOS uses CR+LF (carriage return followed by line feed, '\r\n', 0x0D0A)

And what happens in cases like this is the formatting of the page causes the PHP parser in Apache to choke on the files. Possibly sending content to the browser before you intend to when making header() calls or setting cookies. Meaning technically the screwed up line endings force a “header” to be sent because the file itself is outputting data to the browser inadvertently.

The solution might be to avoid using Dropbox & just copy the files onto a flash drive & transfer it that way. That’s an idea but I am not convinced that Dropbox was the culprit in this. Meaning the issue might still exist even if you copy the files to a flash drive.

Or if that does not work, do as the linked to article suggests & download a good text editing tool like TextWrangler. Just load the files into TextWrangler & then manually change the line endings so they are Mac (CR) and resave the files.

Another long-term solution to this issue might be to use a version control system like git coupled with an account on GitHub to manage your code. The benefit is by pushing code to GitHub & pulling code from GitHub, the process itself will deal with cross-platform line ending headaches. And you don’t need to worry about inadvertent oddities caused by a straight copy of files to a service like DropBox.

But again, pretty convinced this has nothing to do with Dropbox. It’s all about Windows line endings being different from Mac OS X line endings.

EDIT: There are some interesting ideas on how to handle the bulk conversion of Windows line endings to Mac OS X line endings on Mac OS X Hints. The most intrguing one is the use of zip and unzip to facilitate the process. I have not tried this, so caveat emptor! But it does sound like something worth testing since the last line states, BTW, it's the "-a" flag to unzip, that is causing the ascii files to have their lines endings converted.:

I've always used the following (in a file named fixascii):

#!/bin/sh 
zip -qr foo.zip "$@" && unzip -aqo foo.zip && rm foo.zip

And then execute it as:

fixascii [files or directories to convert]

Which has the benefit over most of these other commands in that you can point it with impunity at an entire directory tree and it will process all the files in it and not corrupt any binaries that may happen to have a string of bits in them that look like a line-ending.

I've seen too many times where someone corrupted a ton of images and other binaries, when trying to fix line-endings on text files using dos2unix or tr in combination with find but failed to ensure that only text files were processed. Unzip figure out which files are ascii, converts them, and leaves the binaries alone.

BTW, it's the "-a" flag to unzip, that is causing the ascii files to have their lines endings converted.

And then looking in the official man page for unzip under the -a (convert text files) option; emphasis is mine:

Ordinarily all files are extracted exactly as they are stored (as ''binary'' files). The -a option causes files identified by zip as text files (those with the 't' label in zipinfo listings, rather than 'b') to be automatically extracted as such, converting line endings, end-of-file characters and the character set itself as necessary. (For example, Unix files use line feeds (LFs) for end-of-line (EOL) and have no end-of-file (EOF) marker; Macintoshes use carriage returns (CRs) for EOLs; and most PC operating systems use CR+LF for EOLs and control-Z for EOF. In addition, IBM mainframes and the Michigan Terminal System use EBCDIC rather than the more common ASCII character set, and NT supports Unicode.) Note that zip's identification of text files is by no means perfect; some ''text'' files may actually be binary and vice versa. unzip therefore prints ''[text]'' or ''[binary]'' as a visual check for each file it extracts when using the -a option. The -aa option forces all files to be extracted as text, regardless of the supposed file type.

EDIT: Also, if you have access to a Linux machine, you might want to checkout dos2unix. More details here as well. And found another Stack Overflow question here.

Answer 3

Finally found an easy way to fix this! I was looking through the php.ini file when i came across an option which is named: auto_detect_line_endings, and has its default value set to: Off.

The description to this option is:

; If your scripts have to deal with files from Macintosh systems,
; or you are running on a Mac and need to deal with files from
; unix or win32 systems, setting this flag will cause PHP to
; automatically detect the EOL character in those files so that
; fgets() and file() will work regardless of the source of the file.
; http://php.net/auto-detect-line-endings

Which is exactly what i was looking for!

I simply used the ini_set() function at the beginning of my database file(which i load on every php page) and it seems to have solved the problem for me! The ini_set() function also returns the option changed in the php.ini file to normal when script is completed.

Full line of the ini_set() function that i used:

ini_set("auto_detect_line_endings", true);

Thanks for all your help guys!

More info on ini_set() function here: ini_set() function

More info on the auto_detect_line_endings option here: Auto detect line endings option