Initialising a hash

Discussion in 'Perl Misc' started by Dave Saville, Feb 5, 2014.

  1. Dave Saville

    Dave Saville Guest

    I have a script that processes apache log files.

    One of the items it needs is a "number to english" look up of HTTP
    error codes. There are around 80 of the things.

    Given "200 OK" etc. per line I can see three ways of doing it:

    1) External file, read and parse into a hash with the number as the
    key.
    2) Ditto but have the codes internally under __DATA__
    3) Actually init as a hash - "code" => "english".

    1 is out. I was doing it but forgot all about it and one day deleted
    the file on a "what;s that doing here?" thought.

    I have changed to 2, but just wonder about the pros and cons of 2 vs 3
    - if there are any.

    TIA
    --
    Regards
    Dave Saville
     
    Dave Saville, Feb 5, 2014
    #1
    1. Advertising

  2. "Dave Saville" <> writes:
    > I have a script that processes apache log files.
    >
    > One of the items it needs is a "number to english" look up of HTTP
    > error codes. There are around 80 of the things.
    >
    > Given "200 OK" etc. per line I can see three ways of doing it:
    >
    > 1) External file, read and parse into a hash with the number as the
    > key.
    > 2) Ditto but have the codes internally under __DATA__
    > 3) Actually init as a hash - "code" => "english".


    Considering that RFC2616 defines 41 response codes, I think I'd just
    grap them from the table of contents, use a perl one-liner to munge that
    into 'hash syntax',

    perl -ane '$F[0] =~ /(\d+\.){2}\d+/ or next; $e = $F[2]; $_ =~ /\./ and last or $e .= " $_" for @F[3 .. $#F]; print($F[1], "=> '\''$e'\'',\n");'

    (works for a shell with 'bourne-style quoting rules')

    and include that literally in the code (as 'body' of a hash
    initialization, obviously).
     
    Rainer Weikusat, Feb 5, 2014
    #2
    1. Advertising

  3. Dave Saville

    John Bokma Guest

    "Dave Saville" <> writes:

    > I have a script that processes apache log files.
    >
    > One of the items it needs is a "number to english" look up of HTTP
    > error codes. There are around 80 of the things.
    >
    > Given "200 OK" etc. per line I can see three ways of doing it:
    >
    > 1) External file, read and parse into a hash with the number as the
    > key.
    > 2) Ditto but have the codes internally under __DATA__
    > 3) Actually init as a hash - "code" => "english".


    4)

    use HTTP::Status;

    print status_message( $code ), "\n";



    --
    John Bokma j3b

    Blog: http://johnbokma.com/ Perl Consultancy: http://castleamber.com/
    Perl for books: http://johnbokma.com/perl/help-in-exchange-for-books.html
     
    John Bokma, Feb 5, 2014
    #3
  4. Dave Saville

    Huge Guest

    On 2014-02-05, Dave Saville <> wrote:
    > I have a script that processes apache log files.
    >
    > One of the items it needs is a "number to english" look up of HTTP
    > error codes. There are around 80 of the things.
    >
    > Given "200 OK" etc. per line I can see three ways of doing it:
    >
    > 1) External file, read and parse into a hash with the number as the
    > key.
    > 2) Ditto but have the codes internally under __DATA__
    > 3) Actually init as a hash - "code" => "english".
    >
    > 1 is out. I was doing it but forgot all about it and one day deleted
    > the file on a "what;s that doing here?" thought.


    Which is why I always code the ability to have comments into such files
    and comment them "HTTP Error codes, used by /usr/local/bin/apache_log_report",
    or whatever.


    --
    Today is Sweetmorn, the 36th day of Chaos in the YOLD 3180
    "Mistake Not My Current State Of Joshing Gentle Peevishness For The
    Awesome And Terrible Majesty Of The Towering Seas Of Ire That Are
    Themselves The Milquetoast Shallows Fringing My Vast Oceans Of Wrath"
     
    Huge, Feb 5, 2014
    #4
  5. Dave Saville

    Jim Gibson Guest

    In article <>, Huge
    <> wrote:

    > On 2014-02-05, Dave Saville <> wrote:
    > > I have a script that processes apache log files.
    > >
    > > One of the items it needs is a "number to english" look up of HTTP
    > > error codes. There are around 80 of the things.
    > >
    > > Given "200 OK" etc. per line I can see three ways of doing it:
    > >
    > > 1) External file, read and parse into a hash with the number as the
    > > key.
    > > 2) Ditto but have the codes internally under __DATA__
    > > 3) Actually init as a hash - "code" => "english".
    > >
    > > 1 is out. I was doing it but forgot all about it and one day deleted
    > > the file on a "what;s that doing here?" thought.

    >
    > Which is why I always code the ability to have comments into such files
    > and comment them "HTTP Error codes, used by /usr/local/bin/apache_log_report",
    > or whatever.


    Which is why I always create either a backup system or a configuration
    control system, but usually both.

    --
    Jim Gibson
     
    Jim Gibson, Feb 6, 2014
    #5
  6. On 02/05/14 10:38, Dave Saville wrote:
    > I have a script that processes apache log files.
    >
    > One of the items it needs is a "number to english" look up of HTTP
    > error codes. There are around 80 of the things.
    >
    > Given "200 OK" etc. per line I can see three ways of doing it:
    >
    > 1) External file, read and parse into a hash with the number as the
    > key.
    > 2) Ditto but have the codes internally under __DATA__
    > 3) Actually init as a hash - "code" => "english".
    >
    > 1 is out. I was doing it but forgot all about it and one day deleted
    > the file on a "what;s that doing here?" thought.
    >
    > I have changed to 2, but just wonder about the pros and cons of 2 vs 3
    > - if there are any.


    The main trade off for 2 is that you might someday decide you need your
    __DATA__ section for something less amenable to a 3-ish solution than
    this is.

    Also, I suppose you might one day see the __DATA__ section and say
    "What's that doing here" and delete it. If you are prone to doing that
    sort of thing.

    Xho
     
    Xho Jingleheimerschmidt, Feb 6, 2014
    #6
  7. Dave Saville

    C.DeRykus Guest

    On Wednesday, February 5, 2014 10:38:32 AM UTC-8, Dave Saville wrote:
    > I have a script that processes apache log files.
    > One of the items it needs is a "number to english" look up of HTTP
    > error codes. There are around 80 of the things.
    > Given "200 OK" etc. per line I can see three ways of doing it:
    >
    > 1) External file, read and parse into a hash with the number as the
    > key.
    > 2) Ditto but have the codes internally under __DATA__
    > 3) Actually init as a hash - "code" => "english".
    >
    > 1 is out. I was doing it but forgot all about it and one day deleted
    > I have changed to 2, but just wonder about the pros and cons of 2 vs 3
    >


    I'd combine them:

    my %CODE;
    { local($/,$_); $_=<DATA>; %CODE = /(...)...(...)/mg }


    --
    Charles DeRykus
     
    C.DeRykus, Feb 6, 2014
    #7
  8. Dave Saville

    Dave Saville Guest

    On Thu, 6 Feb 2014 00:47:09 UTC, Jim Gibson <>
    wrote:

    > In article <>, Huge
    > <> wrote:
    >


    <snip>

    > > Which is why I always code the ability to have comments into such files
    > > and comment them "HTTP Error codes, used by /usr/local/bin/apache_log_report",
    > > or whatever.


    Unfortunately I did not look in the file - I just went by the name.
    :-(

    >
    > Which is why I always create either a backup system or a configuration
    > control system, but usually both.
    >


    I do have a backup - but the deletion was over a year ago and I don't
    keep them that long.

    --
    Regards
    Dave Saville
     
    Dave Saville, Feb 6, 2014
    #8
  9. Dave Saville

    Dave Saville Guest

    On Wed, 5 Feb 2014 21:02:03 UTC, John Bokma <>
    wrote:

    > "Dave Saville" <> writes:
    >
    > > I have a script that processes apache log files.
    > >
    > > One of the items it needs is a "number to english" look up of HTTP
    > > error codes. There are around 80 of the things.
    > >
    > > Given "200 OK" etc. per line I can see three ways of doing it:
    > >
    > > 1) External file, read and parse into a hash with the number as the
    > > key.
    > > 2) Ditto but have the codes internally under __DATA__
    > > 3) Actually init as a hash - "code" => "english".

    >
    > 4)
    >
    > use HTTP::Status;
    >
    > print status_message( $code ), "\n";


    Thanks for that - Did not know of it - and I had it :) Specific
    solution but I was also after the general case. Which others have
    commented on.
    --
    Regards
    Dave Saville
     
    Dave Saville, Feb 6, 2014
    #9
  10. Dave Saville

    Dave Saville Guest

    On Thu, 6 Feb 2014 04:08:35 UTC, Xho Jingleheimerschmidt
    <> wrote:

    <snip>

    >
    > Also, I suppose you might one day see the __DATA__ section and say
    > "What's that doing here" and delete it. If you are prone to doing that
    > sort of thing.


    LOL. Much, much less likely to delete a chunk of a script without too
    much thought than a data file that appeared in a cgi directory.
    Actually the decision was slightly more complicated than "Why's that
    here? rm" but the details are irrelevant to the discussion in hand.
    --
    Regards
    Dave Saville
     
    Dave Saville, Feb 6, 2014
    #10
  11. Dave Saville

    Huge Guest

    On 2014-02-06, Jim Gibson <> wrote:
    > In article <>, Huge
    ><> wrote:
    >
    >> On 2014-02-05, Dave Saville <> wrote:
    >> > I have a script that processes apache log files.
    >> >
    >> > One of the items it needs is a "number to english" look up of HTTP
    >> > error codes. There are around 80 of the things.
    >> >
    >> > Given "200 OK" etc. per line I can see three ways of doing it:
    >> >
    >> > 1) External file, read and parse into a hash with the number as the
    >> > key.
    >> > 2) Ditto but have the codes internally under __DATA__
    >> > 3) Actually init as a hash - "code" => "english".
    >> >
    >> > 1 is out. I was doing it but forgot all about it and one day deleted
    >> > the file on a "what;s that doing here?" thought.

    >>
    >> Which is why I always code the ability to have comments into such files
    >> and comment them "HTTP Error codes, used by /usr/local/bin/apache_log_report",
    >> or whatever.

    >
    > Which is why I always create either a backup system or a configuration
    > control system, but usually both.


    Good ideas both, but they don't answer the question, "What's this file
    for?"


    --
    Today is Boomtime, the 37th day of Chaos in the YOLD 3180
    "Mistake Not My Current State Of Joshing Gentle Peevishness For The
    Awesome And Terrible Majesty Of The Towering Seas Of Ire That Are
    Themselves The Milquetoast Shallows Fringing My Vast Oceans Of Wrath"
     
    Huge, Feb 6, 2014
    #11
  12. Dave Saville

    Dave Saville Guest

    On Thu, 6 Feb 2014 11:21:11 UTC, Ben Morrow <> wrote:

    >
    > Quoth "Dave Saville" <>:
    > > I have a script that processes apache log files.
    > >
    > > One of the items it needs is a "number to english" look up of HTTP
    > > error codes. There are around 80 of the things.
    > >
    > > Given "200 OK" etc. per line I can see three ways of doing it:
    > >
    > > 1) External file, read and parse into a hash with the number as the
    > > key.
    > > 2) Ditto but have the codes internally under __DATA__
    > > 3) Actually init as a hash - "code" => "english".

    >
    > There have been a number of suggestions--including the right one,
    > HTTP::Status--but in the more general case I would say 1. there doesn't
    > seem to be any good reason not to write this as plain Perl code but 2.
    > this code should go in a module so it can be reused. That is, if
    > HTTP::Status didn't exist, you should have created it.
    >
    > For the even-more-general case where the data to be represented is
    > complicated enough that it actually makes sense to store it in some
    > other format than Perl code and parse it every time, the fact that every
    > module gets its own __DATA__ section gives you a convenient place to put
    > things. For non-textual data or situations where multiple files are
    > required, you can use File::ShareDir.


    Thanks Ben.

    Maybe I should not have mentioned what the data was as it was the
    general case I was after. OTOH, if I had not mentioned what the data
    was I would not have found out about HTTP::Status. :)

    --
    Regards
    Dave Saville
     
    Dave Saville, Feb 6, 2014
    #12
  13. Dave Saville

    Dave Saville Guest

    HTTP::Status - was Initialising a hash

    On Wed, 5 Feb 2014 21:02:03 UTC, John Bokma <>
    wrote:

    >
    > use HTTP::Status;
    >
    > print status_message( $code ), "\n";


    I have read and think I understood the code of this module. What I
    don't understand is how does one make use of the mnemonics? I can't
    find an example.

    I thought what it did was setup subroutine(s) that take no paramteters
    and return the code number. But anything I tried seems to want one to
    code RC_LOCKED() rather than RC_LOCKED which I thought was the general
    idea.
    --
    Regards
    Dave Saville
     
    Dave Saville, Feb 6, 2014
    #13
  14. Ben Morrow <> writes:
    > Quoth "Dave Saville" <>:
    >> I have a script that processes apache log files.
    >>
    >> One of the items it needs is a "number to english" look up of HTTP
    >> error codes. There are around 80 of the things.
    >>
    >> Given "200 OK" etc. per line I can see three ways of doing it:
    >>
    >> 1) External file, read and parse into a hash with the number as the
    >> key.
    >> 2) Ditto but have the codes internally under __DATA__
    >> 3) Actually init as a hash - "code" => "english".

    >
    > There have been a number of suggestions--including the right one,
    > HTTP::Status--


    The 'right' solution (in the sense of 'sensibly engineered') would be to
    have a textual database file similar to the already existing ones, eg,
    protocols or services, which can be maintained independently of anything
    executable which happens to use it and which is generally useful and not
    tied to a particular 'executable code module' written in a particular
    language.

    If the mapping is hard-coded, anyway, the next most convenient
    thing would to transfer the corresponding hasg from Status.pm to the script
    using it and thus, at least avoid the useless function call and make
    this list maintainble without having to futz around with some third
    party code module prone to being replaced inadvertently without
    realising the damage until a much less convenient later time.

    "Someone else wrote it and I know how to get it for free!" may also be a
    sensible approach, but only insofar this helps avoiding a 'critical'
    competence deficit or to increase the billed_time / actual_work_time
    quotient in order to make someones conslutancy more economically viable,
    although it would be debatable if die-hard 'religious' short-termism is
    such a good idea in the long run.
     
    Rainer Weikusat, Feb 6, 2014
    #14
  15. Rainer Weikusat <> writes:

    [...]

    > increase the billed_time / actual_work_time quotient in order to make
    > someones conslutancy more economically viable, although it would be
    > debatable if die-hard 'religious' short-termism is such a good idea in
    > the long run.


    Personal addition: My arguably limited experience with these people is
    one of 'Caveat emptor' with the 'Caveat' being such a huge part of this
    that 'run away screaming' should be considered as more sound
    alternative, ie, in the end, the code will have to be replaced, anyway,
    if one doesn't want to keep losing deals, while the 'consultant' has long
    since sought a greener pasture elsewhere. I apologize to everyone who
    actually does this as an honest business instead of a 'promise castles
    in the air, get $$$ in return, let someone else deal with the debris'
    scam.
     
    Rainer Weikusat, Feb 6, 2014
    #15
  16. Dave Saville

    Tim McDaniel Guest

    In article <>,
    Dave Saville <> wrote:
    >Maybe I should not have mentioned what the data was as it was the
    >general case I was after.


    I think you should. In my experienc: almost always, when someone asks
    a general question and later gets to the specific details, it turns
    out that the specific details change the answer.

    --
    Tim McDaniel,
     
    Tim McDaniel, Feb 6, 2014
    #16
  17. Re: HTTP::Status

    On 2014-02-06 13:20, Dave Saville <> wrote:
    > On Wed, 5 Feb 2014 21:02:03 UTC, John Bokma <>
    > wrote:
    >> use HTTP::Status;
    >>
    >> print status_message( $code ), "\n";

    >
    > I have read and think I understood the code of this module. What I
    > don't understand is how does one make use of the mnemonics? I can't
    > find an example.
    >
    > I thought what it did was setup subroutine(s) that take no paramteters
    > and return the code number.


    This works for me:

    #!/usr/bin/perl
    use warnings;
    use strict;
    use v5.10;

    use HTTP::Status qw:)constants);

    say HTTP_FOUND;
    say "Location: http://example.com";
    say "";
    __END__

    hp

    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaƟt. -- Ralph Babel
     
    Peter J. Holzer, Feb 6, 2014
    #17
  18. (Tim McDaniel) writes:
    > In article <>,
    > Dave Saville <> wrote:
    >>Maybe I should not have mentioned what the data was as it was the
    >>general case I was after.

    >
    > I think you should. In my experienc: almost always, when someone asks
    > a general question and later gets to the specific details, it turns
    > out that the specific details change the answer.


    There's a general answer to these kind of questions and it is "use a
    textual database in a well-known format which can be maintained
    indepdently of your present code and used independently of the
    programming language your present code happens to be written in". In
    case you'd rather have something simple, use a hard-coded hash _in
    your script_. Suitable places for getting the data are ...

    "Someone else already wrote a script with such a hard-coded list in it
    and made it available for free download, so all you really have to do is
    download it and tack the two scripts together somehow" is not among the
    sensible answers, not even if the code attached to the other hard-coded
    list happens to be useless for anything but accessing it in an
    inefficient way.

    Losely related question: Isn't there a newsgroup for all of this "OMG!
    Free Download available!! Run to get there while stocks last!!!"
    traffic? Or alternatively, is there a newsgroup for questions and
    discussions about Perl and not about "OMG! ..."?
     
    Rainer Weikusat, Feb 6, 2014
    #18
  19. Dave Saville

    Dave Saville Guest

    Re: HTTP::Status

    On Thu, 6 Feb 2014 17:58:15 UTC, "Peter J. Holzer"
    <> wrote:

    > On 2014-02-06 13:20, Dave Saville <> wrote:
    > > On Wed, 5 Feb 2014 21:02:03 UTC, John Bokma <>
    > > wrote:
    > >> use HTTP::Status;
    > >>
    > >> print status_message( $code ), "\n";

    > >
    > > I have read and think I understood the code of this module. What I
    > > don't understand is how does one make use of the mnemonics? I can't
    > > find an example.
    > >
    > > I thought what it did was setup subroutine(s) that take no paramteters
    > > and return the code number.

    >
    > This works for me:
    >
    > #!/usr/bin/perl
    > use warnings;
    > use strict;
    > use v5.10;
    >
    > use HTTP::Status qw:)constants);
    >
    > say HTTP_FOUND;
    > say "Location: http://example.com";
    > say "";
    > __END__
    >


    Not on 5.8.2 :) Seems you need to qw( <the ones you need> ). There
    is no generic that gets the lot. Thanks for the pointer though.
    --
    Regards
    Dave Saville
     
    Dave Saville, Feb 6, 2014
    #19
  20. Re: HTTP::Status

    On 2014-02-06 18:58, Dave Saville <> wrote:
    > On Thu, 6 Feb 2014 17:58:15 UTC, "Peter J. Holzer"
    ><> wrote:
    >> On 2014-02-06 13:20, Dave Saville <> wrote:
    >> > I thought what it did was setup subroutine(s) that take no paramteters
    >> > and return the code number.

    >>
    >> This works for me:

    [...]
    >> use HTTP::Status qw:)constants);
    >>
    >> say HTTP_FOUND;

    [...]
    >
    > Not on 5.8.2 :)


    Probably less a question of your Perl version as that of HTTP-Message.
    On my workstation I have 6.03, on a server with Perl 5.8.0 I have 1.28,
    which indeed doesn't export the :constants bundle. You could probably
    upgrade HTTP-Message, though that might depend on some newer Perl
    version.

    hp


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaƟt. -- Ralph Babel
     
    Peter J. Holzer, Feb 6, 2014
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jan

    Initialising a signal

    jan, Dec 16, 2003, in forum: VHDL
    Replies:
    3
    Views:
    498
    David Jones
    Dec 23, 2003
  2. Jo Inferis
    Replies:
    0
    Views:
    393
    Jo Inferis
    Jun 20, 2004
  3. Phil Winstanley [Microsoft MVP ASP.NET]

    Re: Dynamic user control loading/initialising

    Phil Winstanley [Microsoft MVP ASP.NET], Jun 20, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    398
    Jo Inferis
    Jun 20, 2004
  4. rp
    Replies:
    1
    Views:
    543
    red floyd
    Nov 10, 2011
  5. Srijayanth Sridhar
    Replies:
    19
    Views:
    629
    David A. Black
    Jul 2, 2008
Loading...

Share This Page