In a new post to his blog Sameer Borate includes a handy bit of code you can use to split up a large MySQL dump file into smaller, easier to digest chunks.

One of the frustrating things with working with MySQL is of importing large sql dump files. Either you get a 'max execution time exceeded' error from PHP or a 'Max_allowed_packet_size' from MySQL. In a recent task I needed to import a table of around a million records on a remote host, which quickly became an exercise in frustration due to various limitations on the server. SSH was of no help as changing the configuration files was restricted to the root user. My last resort was to split the huge 'INSERT' statements into smaller size files.

His script needs a little extra time to run (he sets max execute to 600 seconds) and takes the SQL file in line by line, splitting them back out to over files based on a "count" value - "dump-split-*". Depending on the size of your files, using something like this might not be an option. You might need something more like the command line "split" feature to keep it outside of PHP's memory management all together.

Hannes Magnusson has a new post today about an interesting feature of the PHP documentation some might not have known existed - manual pages (man) for PHP functions/methods for unix systems.

For a while I had vim configured to run reflection when I hit "K", but after the PHP documentation team released unix manual pages for PHP I now get the manual page in all its glory; function description, parameter descriptions, return values, examples, notes, see also and everything you are used to see from the online manual. Its awesome.

These manual pages aren't installed by default, so you'll have to grab the download from the PEAR channel for the PHP documentation (doc.php.net/pman). If you're wanting to use it in VIM, you'll also need to change the keywordprg setting to "pman".

Based on a fix for a recent bug, Derick Rethans wanted to clear up something about the Unix Epoc's definition and how it relates to the UTC time zone.

While right now it is proper to define the Unix Epoch at "1970-01-01 00:00:00 UTC", UTC wasn't actually defined until 1972. So it would be more correct to define the Unix Epoch as "the number of seconds elapsed since midnight proleptic Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds." (from Wikipedia).

He talks about the calendar PHP uses internally and how dates predating it's use don't make much sense either (as well as the modified version PHP uses that includes "year zero").

On the SitePoint PHP blog today Troels Knak-Nielsen has a quick tip for those looking for a way to have their command-line PHP scripts be more interactive.

Just a quick tip, since I spent a good hour figuring this out recently. PHP has no native way of doing an interactive password prompt, when running as CLI. You can however use bash for the task.

His method (for both Windows and Unix systems) uses shell_exec command to run a VB Script/bash command that handles the password prompt for the PHP script. The result is then passed back into a variable and returned back to the calling application.

Derick Rethans one of the go-to guys for working with time in PHP has made this new post about something 2008 picked up along the way to 2009 - a leap second.

The start of this new year started with some buzz about a leap second being introduced between Dec 31st 2008, 23:59:59 and Jan 1st 2009, 00:00:00. I've had people ask where this leap second actually comes from, and whether you need to worry about it in your applications. To understand leap seconds means, unfortunately, understanding how time is actually kept.

He ponints out one of the major problems - how time is kept. With variants of Universal Time, it makes it hard to track down what's "right". He breaks out the difference between other time storage methods and the unix time that PHP can use (that counts the number of seconds since Jan 1st 1970) and how the leap second was handled for each.

Permissions in Unix-based systems have become one of the standard models for development all over the world. They're simple to learn and use while being extremely powerful at the same time. In this new article (as contributed by Eric Potvin) from PHPBuilder.com today, they bring this power to the realm of PHP with bitmasks.

Bitmasking is a very useful method to emulate Unix-style file permissions (read/write/execute for example). What's nice about a PHP implementation is that you can configure your own bitmasks and use them for any kind of permissions in your scripts and applications. The implementation is relatively simple as well.

They start by defining a few of the permission levels (add/delete/denied) in PHP constants before showing the bitMask() function you can use to check a user's permissions. They also include some simple pseudo-code to show how it's used. For more information, check out the complete article here.