Well, it’s been almost a month now since the baby came. We’re doing well, but very tired. Adding to my things-to-read-when-I’m-not-so-tired list:
Ruby Code & Style – a new online magazine from Artima about the Ruby language.
A couple of weeks ago I was installing a development environment at work on CentOS with Apache 2, PHP, and the oci8 module. All configured, make’d, and installed, I was up and running with Apache, PHP, and the Oracle Client tools (sqlplus, etc.) in short order. Everything worked except the oci8 php library functions–they couldn’t find my Oracle instances to connect.
I had covered all of the bases:
This problem had me stumped a good part of an afternoon until I attempted to start Apache directly with apachectl instead of through the ‘service’ command used in CentOS. Suddenly, it worked!
A quick shuffle through the service script and I found that it was restricting the environment before calling the service like so:
env -i LANG=$LANG PATH=$PATH TERM=$TERM "${SERVICEDIR}/${SERVICE}"
Hmm. So, only LANG, PATH, and TERM are passed into any service environment: ORACLE_HOME is left out in the cold. And, even though I set it in the httpd.conf file, this is apparently too late for it to make a difference in the php oci8 module. A quick fix in the service script adds the requisite ORACLE_HOME:
env -i ORACLE_HOME=$ORACLE_HOME LANG=$LANG PATH=$PATH TERM=$TERM "${SERVICEDIR}/${SERVICE}"
The line above occurs a few times, so add to each occurance. Voila! It works.
I’m content with this solution for now, but I don’t particularly like having to change the service script, so is there any other way to do this?
Update:This is apparently a common issue: Debian mailing list comment, Gentoo bug, which is fixed with a white list of environment variables in a separate file. I couldn’t find a similar RedHat/CentOS bug. And, the SetEnv in the httpd.conf file is only effective for CGI PHP, which does not work for me because I’m using mod_php
We’re using PHP version 4.x in production at work, and I often find myself needing a function that has been implemented in PHP 5. A good example is the array_walk_recursive() function. I needed this in my framework library to recursively walk through an input array with a callback function to strip values of potentially harmful input. The recursive ability was key because the input array could be arbitrarily large, containing several nested arrays.
Now, I could have implemented my own function to do just this, but when we do move to PHP 5 in production, I’d want to recode to use the standard library function. To the rescue comes the PHP_Compat PEAR package, full of functions and constants to help bridge the gap between different PHP versions.
Thanks to Aidan Lister (the lead developer) and others who contributed to this package. It has saved me much coding, and I’m grateful!
I’m currently reading Programming Ruby (2nd edition) in my pursuit to learn Ruby. This book, known as the PickAxe because of the tool on the front cover, is part tutorial, part language reference, part best-Ruby-practices, and part API/Library reference.
The tendency with a reference book like this is to lump everything about a particular topic into long, boring sections. However, Dave Thomas and co-authors have managed not to do this. The book is good at switching gears frequently enough to keep my focus. Notes comparing Ruby to Perl, Java, and C++ add perspective if you are familiar with those languages. The code samples in this book also set it apart from similar programming books: the examples are concise–giving just enough information to illustrate the point in question.
As I read through the book, I find myself thinking: “Wow, it would’ve taken me so much more code to do that in Java (or C++ or …)!”