Easier sed than done

sed seems to be one of the least used, and possibly most hated of the standard Unix utilities.  But honestly, I think it gets a bad rap.  Sure, it seems to have a steep learning curve, but vi did too when I first started.  It's just that I use vi heavily, on a daily basis.  Not so much sed.  I must admit, my sed skills are sketchy at best.  I can only produce meaningful sed scripts with a good reference, but it's often the best tool for the job.

Good Preprocessor Usage

I was digging through some code and came across the following preprocessor construct:

#if FOO == 0
void foo(int bar)
{
#endif
#if FOO != 0
void foo(float baz)
{
#endif

As a general rule, conditionally-compiled code makes the hairs on the back of my neck stand up, but given that this is code for embedded systems, and the same basic code runs on a number of different hardware platforms, I understand that it is sometimes a necessary evil.  The problem is, people don't always treat preprocessing directives as what they really are: code.  They're instructions processed by a computer, and deserve the same good coding practices that one would apply to the rest of their source code.  Preprocessor code may actually deserve more attention to best practices due to the difficult nature of debugging it.  Taking the above as a case study, here are a few thoughts on how to improve this:

Dynamic Greasemonkey Scripts

A friend and I recently did some work for a client creating a small Greasemonkey script.  Greasemonkey is a nifty little tool that lets you run custom scripts on webpages of your choosing.  These scripts are written in JavaScript and are local to your machine, not served up from some remote server.  They let you make changes to web pages on the fly, as if you got to write your own JS for that page.

The GM script had to work for Firefox and Chrome.  Firefox requires an extension, whereas chrome recognizes a GM script automatically.  The task seemed pretty easy.  We needed to dynamically create a GM script to be installed on the user's system.  All a GM script really needs is some JS with a few special comment fields at the top of the script, and you're ready to rock and roll.  No biggie I thought, I'll just hack up a quick PHP script to spit back the custom JS...no dice.  It turns out that the GM plugin in Firefox and Chrome's auto-detection require that the file name end in .user.js.  Well, this posed a problem.  I need a file ending in .user.js to be served up by the web server, but I needed it to have dynamic content.  I can't write the dynamic parts in JS since a GM script doesn't actually get executed by the browser when served, it get's preempted by the plugin/module, and offered for install as a user script.  I couldn't make a PHP script spit back the GM script because the plugins would refuse to install something ending in .php.

Welcome!

I guess I'm only welcoming myself for now, since nobody else reads this (yet).  It's about time I got one of these things going.  I still have no idea what direction this thing will take, but I might just let it steer itself and enjoy the ride.  I figure there will be a fair amount of techie stuff here, mostly revolving around C, embedded programming and maybe some PHP extensions.  Hobbies include brewing, surfing, working on cars and houses, so some of that will likely pop up.  And I like to follow current events, politics and economics, but on a somewhat light level, so you might see the occasional post about that.  I like to ponder math, religion, philosophy, literature and linguistics, so a bit of that might come up too.  Basically, nothing is off limits, but I'll try to keep it to polite dinner table conversation.  So check back from time to time, and hopefully you'll find something interesting.