The instructions you reference require wget which didn't seem to be available to me in the command line, which is why I used the instructions I did.
Running through the various tests I got that pear's include path should be /usr/lib/php/pear, but phpinfo() was telling me the include path was .:
The line in php.ini for include path was commented out, with the value ".:/php/includes". I changed this to "/usr/lib/php/pear" - should I have left the ".:" before the first slash? Don't want to mess up anything that was working before.
phpinfo now shows the include path as /usr/lib/php/pear of course.
The test now works as it appears does my script. But worried I might have broken things (not yet discovered) by removing ".:" from the old path.
I do seem to have run into another problem - something in the pear file HTTP/Request.php is force-adding "www" on the beginning of my URL (http://mysite.dev becomes http://www.mysite.dev on my dev instance). It seems to be simply the act of requiring HTTP/Request.php - I'm not instantiating a class. When I remove the class HTTP_Request from the file Request.php the problem goes away. But can't figure out what in it might be forcing this redirect, especially since I'm not instantiating anything.
I changed this to "/usr/lib/php/pear" - should I have left the ".:" before the first slash? Don't want to mess up anything that was working before.
Yes, the include_path entry lists the directories in which PHP is supposed to look for included files (separated by colons). "." refers to the current directory of the script being executed - without it PHP won't think to look there.