Common Media, Inc. » Code

Simple Perl scripts for OS X users using Platypus

pjmorse — Mon, 12 Jul 2010 14:31:43 +0000

Maybe everyone who’s ever done anything with Perl has written an email extraction script, but a recent client request asked us to take it one step further: allow the script to function as a Mac OS X “droplet.” In other words, the script should be an icon in the Finder, and when files are dragged and dropped on the icon, it should run the script.

This was easy in the days of Mac OS 9 and MacPerl; because there was no Unix core to the Mac OS, MacPerl was the only Perl environment, and the MacPerl environment took care of things like drag-and-drop file access (after all, that was the only way to provide a filename as an argument to a Perl script on a Mac.) Nowadays, with a standard Unix-y Perl shipping with the Mac OS, MacPerl is no longer needed, but the handy drag-and-drop functions aren’t there.

Filling the gap is Platypus, a handy little utility which makes application bundles out of Unix scripts. Notice I didn’t say “Perl” there. Platypus plays nicely with shell scripts, Python, PHP, Ruby, and Tcl just as easily as Perl. As the developer describes it, “this is done by wrapping the script in an application bundle directory structure along with an executable binary that runs the script.”

Advanced options allow you to configure how script output is shown, whether to allow dropped files as input (you can also filter which file types are accepted) and what to do at script conclusion.

In the case of our email extraction utility, which originally spat out the addresses it found on STDOUT, we found that displaying the script output in a text window for some reason only read one input file. We adjusted the script to write output to a file, then used the text window to show which files were read and the path to the output file (as well as any errors), and that adjustment allowed for multiple input files.

If you’ve ever wanted to double-click your scripts rather than running them from the command line, give Platypus a look.

Quick HTML/CSS demo

noah — Fri, 07 May 2010 14:26:44 +0000

People often ask us what we do when a designer sends over a PSD, so I made some screen captures from the early stages of a recent build. Next time we’ll do a longer one, right through getting all the fonts and images perfect.

Design by our friend Justin Zucco, and I’ll post a link to the live site (Balmat Law) when it goes live in a week or two.

http://www.youtube.com/watch?v=mSC84CUx_Uk

Python package trouble? Check your python

pjmorse — Sat, 19 Dec 2009 20:45:36 +0000

This is exactly the sort of low-level stuff you’d think everyone should know, but I searched an error message today and didn’t get a useful answer. I found one, so here it is for the next searcher.

If you’re trying to build a Python package (in my case, the ReportLab toolkit), and your build fails with a string of error messages starting with Python.h: No such file or directory, the problem is that the package includes some amount of code which is written in C. The build is trying to compile that code, and the C compiler is looking for the Python C headers, and for most Linux users (I ran in to this on an Ubuntu system) the C headers aren’t part of the core Python package. You need the python-dev package. Try this:

sudo apt-get install python-dev

Then try your build again; I bet it will work.

XSL namespaces for HTML output

pjmorse — Wed, 15 Jul 2009 20:30:08 +0000

One of our current projects involves an application where certain PHP scripts request XML from a SOAP service, then use XSL templates combined with parameters set by the PHP script to generate XHTML from that XML. (Follow that? If not, you may be able to safely skip this.) We haven’t had to cope with setting up this system, but we did have to update the HTML produced by the XSLT, if that’s the proper verb.

The problem we ran in to was getting around Internet Explorer’s quirks mode. The original XSL templates use a bare xsl:output tag with few options, and a bare html tag to start the output code as well, like this:

This produces HTML with no document type and no XML namespace, which means IE is going to go to Quirks Mode, which we don’t want because it hurts our carefully-crafted CSS. We want something more like this:

First, we tried just adding the xmlns attributes to our html tag. This didn’t really help: it added extraneous xmlns="" attributes to many of the child tags in the output document, which quirkified IE just as much as not having the tag.

Solving the second part of the first problem (producing a document type tag) turned out to also be the solution to the second problem (extraneous xmlns attributes). XSLT will add a document type tag automatically if the appropriate attributes are given to the xsl:output tag. Specifically, we wound up with this:

Notice the bonus encoding, doctype-public and doctype-system attributes. That got us the DOCTYPE tag shown above, and bailed us out of IE Quirks Mode.