To debug PHP you usually install the excellent XDebug and so did I with the port command sudo port install php5-xdebug. After that php -v greeted me friendly on the command line already:

PHP 5.3.8 (cli) (built: Sep 22 2011 11:42:56) 
Copyright (c) 1997-2011 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2011 Zend Technologies
  with Xdebug v2.1.1, Copyright (c) 2002-2011, by Derick Rethans

Eclipse Indigo and Eclipse PDT 3 was already installed, so I thought it should be easy to set up the XDebug debugging option in Eclipse. Under “PHP > PHP Executables” I therefor selected /opt/local/bin/php as my CLI version and selected “xdebug” as debugging option.

A first test however showed me that the execution of a test script did not load any module into the PHP interpreter beforehand (for reasons I could only guess, because Eclipse error log kept quite). Looking at the output of phpinfo() from my test script and php -i from command line showed me the difference: The PHP option “Scan this dir for additional .ini files” was empty when PHP ran inside Eclipse, but was properly set when PHP ran from command line (or in an Apache context).

Asking aunt Google brought up this issue that shed some light into my darkness: The directory where additional modules reside is configured as a compile time option in PHP and defaults to /opt/local/var/db/php5 on MacPorts and exactly this can be overridden by either calling PHP with -n -c options or by setting the PHP_INI_SCAN_DIR environment variable.

Having no access to the actual PHP call from inside Eclipse I tried to go down the environment route, but that did not lead to any success. While the variable was recognized as it should on the normal command line (e.g. PHP_INI_SCAN_DIR= php -i disabled the load of additional modules), in Eclipse’ run configuration dialog, in the section environment variables, this was not recognized at all. I tried a little harder and configured the variable inside ~/.MacOSX/environment.plist, logged out and in again, restarted Eclipse obviously, but had no luck either.

The only viable solution I came up with was to place all the single extension= and zend_extension= entries directly into my php.ini and disable the individual module.ini files altogether. At least I can now run and debug properly, but this solution is of course far from being ideal – as soon as I add a new PHP module or want to remove an existing, I have to remember to edit the php.ini myself.

By the way, I also tried to use Zend’s debugger (and PDT plugin) as an alternative. While somebody else already ranted about that the Zend guys have been unable to provide the Zend Debugger for PHP 5.3 as a standalone download (which hasn’t changed to date), PHP 5.2 debugging worked nicely with the old Zend PDT plugin.

Of course, none of my needed PHP modules were loaded and I really needed PHP 5.3 support, so I had to follow the same route the other guy did and downloaded all of the ZendServer glory (a 137MB download, yay) just to get the right ZendDebugger.so. After extracting the .pax.gz archive from the installer package I quickly found it underneath usr/local/zend/lib/debugger/php-5.3.x/, copied it to my extension directory and added an ini file to load that one instead, just to find out shortly afterwards that the Zend binary was i386 only and MacPorts of course compiled everything nicely as x86_64 – php was of course unable to load such a module.

Well, the moral of the story is – go for Xdebug and don’t loose the track. And, let us all hope that Eclipse PDT is developed further, so the remaining glitches like the one above are fixed.

try { ... }
catch (Exception e) {
  throw new CustomException("something went wrong", e);
}

and if you look at the stack trace of the newly thrown exception, the original one is listed as “Caused by:”. Now today I had the rather “usual” use case of cleanup up a failing action and the cleanup itself was able to throw as well. So I had two causing exceptions and I wanted to conserve both of them, including their complete cause chain, in a new exception. Consider the following example:

try { ... }
catch (Exception e1) {
  try { ... }
  catch (Exception e2) {
     // how to transport e1 and e2 in a new exception here?!
  }
  throw e1;
}

My idea here was to somehow tack the exception chain of e1 onto the exception chain of e2, but Java offered no solution for this. So I hunted for my own one:

public static class ChainedException extends Exception {
  public ChainedException(String msg, Throwable cause) {
    super(msg, cause);
  }
  public void appendRootCause(Throwable cause) {
    Throwable parent = this;
    while (parent.getCause() != null) {
      parent = parent.getCause();
    }
    parent.initCause(cause);
  }
}

Now I only had to base the exceptions I actually want to chain on ChainedException and was able to do this (in fact I based all of them on this class):

try { ... }
catch (ChainedException e1) {
  try { ... }
  catch (ChainedException e2) {
    e2.appendRootCause(e1);
    throw new ChainedException("cleanup failed", e2);
  }
  throw e1;
}

Try it out yourself – you’ll see the trace of e1 at the bottom of the cause chain of e2. Quite nice, eh?

1. Click on the clock in the status bar to enable / disable this mode altogether
2. A swipe from the left to the right emulates the Menu button function
3. A swipe from right to left emulates the Back button function
4. Simply clicking on the status bar brings you to the Home screen

(Source)

The first thing to notice is that starting with Mac OS X 10.6 (Snow Leopard) ACLs are always enabled and cannot be disabled as in earlier versions. All ACL commands are baked into the chmod command and parsed from a string you give it with the ‘+a’ option. The basic syntax here is

$ chmod (+|-|=)a#? '<user> (allow|deny) <list-of-permissions>'

Since there is no setfacl on Mac OS X, there is no getfacl either, so ACLs are instead queried by the special option -e of ls:

$ ls -le .
[...]
-rw-r--r--+ 1 john users  175  5 Jun 00:23 foo
0: user:dave allow write

Permissions include the usual read, write, delete, add_file, and add_subdirectory as well as more exotic ones like {read,write}extattr, {read,write}writesecurity and chown. (Read up chmod‘s man page what these are for.)

There are, however, two more important ones to notice, namely file_inherit and directory_inherit. These two let you spread your permissions nicely to sub objects and thus let you for example set up a directory, in which a pool of users is allowed to access, modify and delete each other’s files:

$ chmod +a 'john allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /data
$ chmod +a 'dave allow read,write,delete,add_file,add_subdirectory,file_inherit,directory_inherit' /data

The above example gives john and dave inherited read, write and delete permissions to all file objects underneath /data.

Since ACLs are executed in order, they can also be set in an ordered manner. chmod has the +a# option for that, where # is the position into which the ACL should be added. Similarily, existing ACLs can be edited with =a#, where again # marks the position of the ACL to edit, and deleted with -a#.

Finally, if one wants to get rid of all ACLs of a specific node, chmod -N <path> will do the job.

Thats it, have fun playing with ACLs on Mac OS X!

echo .dump | sqlite3 mydb.db |\
  egrep -v "\b(BEGIN TRANSACTION|COMMIT|PRAGMA|sqlite_sequence)\b" |\
  perl -pe 's/^([^'\''"]*)"([^"]+)"/\1`\2`/' |\
  perl -pe 's/\bautoincrement\b/auto_increment/' |\
  mysql -uroot mydb

The most important line is probably line 3: SQLite encapsulates all table and column names in double quotes and this is not understood by MySQL, so we’re replacing them with backticks. One must be careful here, though, because data INSERTs might also contain double quotes and to avoid having these wrongly replaced as well we only replace them until we encounter the first single quote (these are used in SQLite to encapsulate strings).

Line 3 might also have to be called several times in a row in case multi-column indexes are part of the schema as well, as it will only replace the very first, but no subsequent matches. (I couldn’t get zero-width lookbehind to work properly to remedy this problem; help is welcome.)

Imagine you have hundreds of source code files where somebody once had the great idea to add a version property into each class:

With Perl the line in question is easy to remove:

But, there is one problem: Perl processes each line of the file separately when it slurps in the file, which results in unwanted empty lines:

Then I stumbled upon this article and the solution is to set a special input separator to let Perl slurp in the file as a whole:

and voila, we get what we want:

Digging a little deeper what -0777 actually means leads us to perlrun(1):

The special value 00 will cause Perl to slurp files in paragraph mode. The value 0777 will cause Perl to slurp files whole because there is no legal byte with that value.

Another day saved – thanks to Perl!

And while we’re at it, have a look at Rakudo Star, the best Perl 6 compiler which was released just recently. Perl 6 is in my humble opinion one of the well-designed languages I’ve came across so far, so if you find some time, go over and read the last christmas special, its really worth it!

Host very.secure.server
    IdentityFile ~/.ssh/id_dsa
    IdentitiesOnly true

The second entry, IdentitiesOnly, forces SSH to only use known identity files and not look for more available identities f.e. from a running ssh_agent instance (which are always tried in first instance as it seems).

Getting the logger in web context is easy, all you have to do is

but its a little harder to do for the command line task.

By default no symfony context is created for a command line task and even if it is created, the above call returns an instance of sfNoLogger. Logging in command applications happens through the sfTask::logSection() method, which basically throws an event at the created dispatcher in SYMFONYDIR/lib/command/cli.php. There you can also see that an instance of sfCommandLogger is created, but there is no way to get your fingers at this instance, because its purely local.

So what can we do? Parametricizing the business method with the sfTask instance and using the logSection() is obviously no solution, because this would break in web context where no such sfTask instance exists…

My solution was a bit more straight forward – I simply decided to not use the task-supplied logging schema at all, but created my own logger like this:

Hope this helps somebody.

Unfortunately Thunderbird 3 has only a global option to enable / disable the search database and the indexer, but a smart guy has filled this gap with his extension GlodaQuilla. After you’ve installed it you can configure so-called “inherited properties” for every account

… and every folder, easily overridable simply by toggling the “inherit” option:

I’d prefer that the Thunderbird guys would build this right into the product itself, but until that has been done this add-on is a life saver!

$ cat
^R

If this works, append the following keybinding to your ~/.zshrc:

bindkey '^R' history-incremental-search-backward

(Source)