in reply to Cable modem status

I'd put the license stuff into POD rather than a big (messy to edit) comment. The short comments describing most lines actually obscures the code - I'd put them at the end of the line and omit some of them altogether. Otherwise, good stuff and insperation to do something similar with my modem!

DWIM is Perl's answer to Gödel

Replies are listed 'Best First'.
Re^2: Cable modem status
by ruzam (Curate) on Feb 17, 2007 at 03:19 UTC
    One thing I didn't like doing was changing the first regex match: 
    $content =~ m{
    Frequency(\d+\sHz)\s
    Signal\sTo\sNoise\sRatio([\d.]+\sdB)\s
    Power\sLevel([\d.-]+\sdBmV)
    }xi or My_Die('content failed!');

    [download]
    When I wrote it, it was a much simpler one line, no 'x' expression with spaces instead of '\s' like so: 
    $content =~ m/Frequency(\d+ Hz) Signal To Noise Ratio([\d.]+ dB) Power
+ Level([\d.-]+ dBmV)/i
    or My_Die('content failed!');

    [download]
    But the line was too long to fit the line length on Monks and wrapped (like here). So I massaged it to fit within the column limit, but I think the new format is much less readable than the original. Any ideas on how to improve that?
[reply]
[d/l]
[select]

      well, the conventional wisdom is use a module to parse HTML and I was tempted to make that comment first time around. However the regex seemed sufficiently trivial that it didn't seem really to matter. Using something like HTML::TreeBuilder would sure make it easier to dig the data out for a lot of modems though - mine (which uses a table) for a start!

      If you are going to use /x then take advantage of it and use some white space to break up the different components of the regex so they are easier to parse by eye. Consider:

      $content =~ m{
    Frequency(\d+\s Hz)\s
    Signal \s To \s Noise \s Ratio([\d.]+ \s dB)\s
    Power \s Level([\d.-]+ \s dBmV)
    }xi or My_Die('content failed!');

      [download]
      DWIM is Perl's answer to Gödel
[reply]
[d/l]
        Ah, that's the ticket! Much easier on the eyes. Thanks for the suggestion.

        I wanted to keep it light weight and avoid bringing in any more modules than necessary (right or wrong, that's just my way). The Motorola uses tables to display the data as well which is why I sucked off the row/column tags (s!</?t[dr]>!!g). As it turns out the page generated by the modem isn't 'correct' html anyway. The last row on the 'Signal' page ends with a <tr> instead of a </tr> which prompted me to simply snuff the tags in the first place. I suspect other modems that do this are similarily 'simplistic and possibly incorrect' in their web page designs.

        Speaking of other modems, the other service provider in my area is the telephone company (it's a two horse town when it comes to local internet). I'm currently tracking down the make and model of the Telco's latest offering to see what possiblities lie there. On the one hand it would be nice to have one script do it all, but on the other, for what little code there actually is, it probably doesn't make much sense bloat it out for generic modem types.
[reply]

In Section Cool Uses for Perl