I'm going to be a TV host
I was recently contacted by an associate who asked if I'd be interested in appearing as a guest on a new TV show pilot; needless to say, I agreed. Yesterday I arrived for the recording.

"How are you feeling?" I was asked.
"Nervous," I admitted.
"Well, you'll be more nervous in a moment."
"Really? Why is that?"
"Well, instead of having you as a guest, we were wondering if you'd like to be a TV host. For the whole season."

Apparently being a TV host is a lot less work than I would have expected, because in a 30 minute episode there's only 24 real minutes of show (the rest are taken up with credits, "words on our sponsors", etc), and after segments and specials and reviews and the like, I'll only be on air for maybe 12 minutes in total. In an eight hour day of recording it's reasonable that we'll get at least 36 minutes worth of decent footage, so we can potentially knock over half-a-season in a weekend. Of course, that's all assuming that as a host all I really need to do is look good in front of the camera.

The show looks like it will be called "The Geek Show", will run on channel 31, and start showing in September. All this is still a little provisional, since there's quite a few hurdles to jump before then, but it's still very exciting!

Flame, who some of my readers may know from his OSDC presentations, is the main driving force and creative talent behind the show. And this isn't the only FOSS-friendly, geeky TV show that I hear is in the works. However I don't know if I can talk about the others.

The ironic part of all this is that my channel 31 reception is awful, so I'll probably have to go visit friends to watch the show each week. ;)

Perl Tip: Building Perl Executables with PAR
I think that PAR, the Perl Archiver, is just fantastic. Rather than having to worry about dependencies, and getting a whole raft of modules installed onto my target system, I can just drop them all into a Perl Archive and be done with it. Best of all, using the pp command, I can build an executable that will run even without perl installed at all!

As such, it's no surprise that our latest Perl Tip from Perl Training Australia is on Building Perl Executables with PAR.

For those interesting in getting our tips when they come out, there's both a mailing list and an an Atom feed that you can subscribe to.

SweeperBot - Play MineSweeper Automatically!
My latest project has finally been launched. See SweeperBot.org for the latest in Windows productivity software. Even if you don't use Windows, do watch the 50 second video on the site; it represents a whole day of my life spent poorly, and I think it's hilarious. ;)

For anyone wondering, yes, it's written in Perl. It uses PAR/PP to package the whole thing up into a single Windows executable. Yes, it plays MineSweeper acceptably well, thanks to Audrey Tang showing me the cheat codes at OSDC a few years back. ;)

Rate a CPAN module today!
One of the tough challenges facing someone new to Perl, or even someone who has been using it for years, is navigating the huge number of modules available via the Comprehensive Perl Archive Network (CPAN). CPAN is very comprehensive, with the little stats in the corner listing 6,500+ authors, 15,000+ distributions, and 55,000+ modules. That's a lot of code.

Unfortunately, being faced with so many options can be daunting. The search.cpan.org interface tries to show the most relevant results first, and seems to pay a good amount of attention to CPAN Ratings, and rightly so. In order for a module to be rated, someone has to get themselves a bitcard account (usually meaning they're a CPAN author themselves), use the module, and have the time and passion to write a review. This means that when such reviews do come in, they're highly relevant.

Unfortunately, not very many modules have been given reviews, and often those reviews are given to modules that already have a substantial number already, like DBI. Yet it's the modules that don't occur commonly in literature that need the reviews the most.

So, dear reader, today I wish to give you a quest. Go to CPAN Ratings, search for a module you use, and if it doesn't have a review, write one. That's it, just a single review. I don't care if you love the module or hate it, just let the world know how you feel. It can be a single sentence if you like. Heck, you can even critique one of my modules if you want. Just write a review.

If you don't know where to start, go to a piece of code you've worked on, or the tests for that code, and just look at the use lines. Trust me, you'll find something you care about. It may even be something that was so simple and easy to use that you had forgotten all about it.

Finally, if you're itching to start a new project, and need an idea, turn CPAN Ratings into a game, the same way it was done with the CPAN Testing Service and Kwalitee, or PerlMonks and their XP system. New reviews on a module give you +2 points, reviews on a module that already has reviews give you +1 point, each person who found your review useful gives you +1 point, and each person who didn't find your review useful gives you -1 point.

IPC::System::Simple released - Cross-platform, multi-arg backticks
One of my greatest itches with Perl is the difficultly in doing things correctly with the system() command, which allows one to run a process and wait for it to finish, and backticks (aka qx()), which allows one to run a process and capture its output.

It's not that these commands are hard to use. system("mount /dev/backup") and I've got my backup media mounted. my $config = qx(ipconfig) and I've got my Windows IP configuration. They're dead easy to use, they're just a pain to tell if they worked.

After running, these commands set a special variable named $?, or $CHILD_ERROR if you've told perl to use English. This variable is designed to be "friendly" to "C programmers", who are familiar with the return value of the wait() system call. But who on earth wants to be familiar with the return value of wait()? After teaching thousands of people Perl over the last seven years, I've only had two people admit to know what the wait() return value looks like, and both of them needed therapy afterwards. It's a packed bit-string, and is grossly unfriendly for anyone to use in any language.

So, the usual state of affairs for many developers is they go through their day using system() and backticks and completely ignoring $?, because it's too hard. Then one day a disaster happens where they discover that all their backups are empty, or all their files are corrupted, or all their furniture has been repossessed, because their calls to system() have been failing for years, but nobody noticed because $? was too ugly to contemplate.

Those developers who have been through this process, or seen other people's lives ruined usually try to take a little more care. They recall that $? will be exactly zero if the process ran to completion and returned a zero exit status, which usually indicates success. Their code becomes littered with statements like $? and die $? or system(...) and die $?. That makes them feel warm and fuzzy until they discover it doesn't work. Their command may legitimately return a range of statuses to indicate success, and a whole bunch of things to indicate failure. Worse still, printing the contents of $? as an error message is worse than useless. Nobody understands what the hell it means; if you did, you wouldn't be printing it.

The end result of all this is that Perl sucks at something it's supposed to be good at; namely firing off system commands and being awesome for system administrators. It is this problem that IPC::System::Simple solves.

Put simply, if you're using IPC::System::Simple, you can replace all your calls to system() with run(), and all your calls to backticks with capture(), and it will all work the same way, except that you'll get incredibly useful messages on error. Got a funny exit status? It'll tell you what it is, and the command that caused it. Killed by a signal? You'll get not just the number, but its name, as well a whether it dumped core. Passed in tainted data? You'll get told what was tainted. And it gets better.

Let's say that you're using rsync to backup your files from an active filesystem. It exits with 0 for good, and 24 for "files went missing". On an active filesystem, files disappearing can be considered normal, so we'd like both of these to be considered 'fine'. Anything else, we'd like to get told. Can we do this with IPC::System::Simple? We sure can! Just provide the list of acceptable exit statuses as the first argument:

run( [0,24], "rsync ....")

IPC::System::Simple's run command also works the way that the Perl security pages say that system() should run. That is, when called with multiple arguments, it bypasses the shell. Perl's regular system() when called with multiple arguments will go and use the shell anyway when on a Windows system, which is bad if you were trying to avoid shell meta-characters.

You can get the same shell-bypassing behaviour with capture(); just pass it in multiple arguments and you're done. This even works under Windows, which normally doesn't even support shell-bypassing pipes, let alone checking your command's return values and formatting your errors afterwards. You even get the full 16-bit Windows exit value made available to you, which is something $? and its dark terrors will never give you.

Best of all, installing IPC::System::Simple is a breeze. It's pure perl, with no dependencies on non-core modules. Even if you have no other way of installing modules, you can just copy the .pm file into an appropriate directory and you're done.

Don't put up with the tragedies and uncertain futures that system() and backticks can bring. Use IPC::System::Simple and make handling your system interactions correctly a painless experience.