I am going to try something new here. I need to write an app in Perl to parse the output of Cygwin's CygCheck.exe utility. I say "parse" as a shorthand for "read, munge, output" ;-)

What is new is that I am going to try writing the spec for the app as a Meditation on PMo first before I start the app. Well, I know me, so I am already lying. I'll start to write the spec here, and then start the coding. Then return to this writeup.

"Huh? Why?"

Just to do something fresh, to break some habits. I am not looking for upvotes or for a way to promote my app (although I do intend to publish it; there will be a link in the post sooner or later). The habits I want to break involve the organic way my coding usually proceeds. I start out with an idea, code the skeleton, look for what breaks, decide to add some features, code, repeat, lather, rinse, repeat. It's fine, its what I enjoy. It's also not as disciplined as other approaches, leads to featuritis, and so on.

(As per the top heading), I think the best way is to start with a Perl-OO approach from the beginning. That is really the realization that prompted this idea to write a Meditation. The realization is that these days, I really have no idea where to start with writing Perl-OO code. There are so many Perl-OO memes out there. There are so many helper modules on CPAN that template-ize or automate the creation of objects. Damian's book is considered a good primer, but out of date. <hands pulling out hair>. So where to begin?

I'm not going to wait for advice before I make some decisions and plunge in. For a PMo newbie that would be fine, perhaps, although I do think that a lot of our newer posters don't show that they get that they need to post code from the top of their Question ...but that's neither here nor overthere.

Event-driven

I know that I want to treat my input as a sequence of events. Roughly, the input data is a series of sections that describe system configuration and status data for the Cygwin installation. I will run the CygCheck.exe tool with the flags -v -s -h -r to get verbosity, helpful hints, and Registry queries.

The shape of the input data

A first glance at the input we expect breaks down like this (note: to an extent this is misleading and contrived, because the CygCheck utility outputs some data that is not for public publishing).

• Cygwin Configuration Diagnostics

• Path: D:\UserSW\root\bin

• Output from D:\UserSW\root\bin\id.exe

• Here's some environment variables that may affect cygwin:

• Here's the rest of your environment variables:

• Scanning registry for keys with 'Cygwin' in them...

• Cygwin installations found in the registry:

• Listing available drives...

• Mount entries: these map POSIX directories to your NT drives.

• Looking to see where common programs can be found, if at all...

• Looking for various Cygwin DLLs... (-v gives version info)

• Checking for any Cygwin services...

• Cygwin Package Information

Sweet, Eh?!

This gives a Perler a true-life opportunity to test themselves against some perversely difficult input. These "headings" are highly irregular (arbitrary) in format; it may be that Localization will affect this output (I have no idea), etc.

Preliminary Spec

What will be "success":

• The “section events” will all be detected;
• All data within each section can be manipulated (filtered, reformatted);
• Any section can be removed from the output;
• No “unhandled” text data will be lost after the input stream is terminated.

Design:

• Each section will be represented in code as an object with attributes (properties, methods).
• There will be at least 2 "dump" or "stringification" methods common to all instance/objects: plain text and YAML.
• There will be a "filter" method for each instance/object that will receive a coderef as @_[1].
• Each instance/object will know where in the input stream its instantiating triggering event occured.
• There will be a common / consistent “placeholder” string representation for elided data.

And there we have it. Time to start coding ;-)