1. You've confirmed that /usr/local/php5/bin/php is the correct location of the PHP 5 parser on your server?

2. The -f flag appears to be unnecessary in this case. If you use any command line parameters along with -f, you need to use the -- flag.

3. You might consider using the -q flag to silence page header output.

4. Something easily overlooked: the environment  you're running in is much different than when you're running from a Web browser. Here, you are running on the Linux command line, and there's a lot of stuff set up by the Apache server that you don't get. Make no assumptions about your environment settings or even what directory you are starting in. Be very explicit about full paths and settings.

644 is fine for a PHP (.php) file. LP does not require it to be 'executable' (755). 766 is bad on several points: 1) you don't need owner's execute bit on, 2) you don't want to give 'group' and 'world/others' write permission. I don't know if suPHP is involved from the command line, but if it is, it may not even let you run the script (world writable).

No. By default, cron jobs using just "php" will continue to use PHP 4. Cron jobs and your web site are two different things. If you need PHP 5 functions in your cron job, you will then need to fix each command. Otherwise, you can leave it as-is.

you can also setup cURL to run your PHP crons due to the fact of the commands you are trying to use is strictly PHP4 commands only.

This particular issue has been discussed before but to also provide further clarification on PHP5 cron jobs. The shared servers use a dual PHP configuration which enables you to switch from version 4 to version 5 and vise-versa.  Try to remember that cron jobs are going to use the version 4 commands, since the server is not PHP5 dominant. You only need to use cURL or HTML to run a PHP5 cron job as well.

E.G. I have a cron job in PHP5 I need to run so I decided to add in the HTML path which would be /usr/local/php5/bin/php -q /home/USERNAME/public_html/FOLDER/myPHP5File.php as provided by automania or use the cURL command. I would always suggest using the example provided by automania as it is the easiest and providing the direct path the cron job insures no issues later down the line.

There are applications still out there that can't use PHP 5. They might use long array names (for instance, $HTTP_POST_VARS instead of $_POST) or use some other obsolete functions or facilities, such as deprecated "ereg" functions and certain session functions. Anyway, it does no harm to continue to offer PHP 4 for the time being. Users have to realize that there is little or no support for it (a security problem might not get fixed), so they should be using this time to upgrade their applications to work with PHP 5 anyway (and PHP 6 is on the horizon). Fortunately, it's not rocket science to eliminate register global variables, long array names, ereg and session functions, etc., just a bit of work. Eventually, LP will have to withdraw PHP 4 due to lack of support, and users who haven't bothered to upgrade their applications will have to scramble.

Add: LP could smooth the transition by first making PHP 5 the default version, and requiring users to manually switch on PHP 4 in .htaccess (the opposite of what's done today). That way, users wouldn't be stranded by this wakeup call, but could turn on PHP 4 while they patch their code, much as they do today if they still use register global variables (enable it in php.ini). Eventually, PHP 4 would entirely go away.

Not a bad suggestion either. Configuring cUrl crons isn't too hard.