Hey Jame!   
      
    JC> I like modules for putting common Perl code in   
      
   The 'problem' with that from my perspective is that the common code   
   is already a builtin in perl, {,un}pack, so there is little to nothing   
   that benefits from modularization.  Also by not modularizing it is 100%   
   compatible with microperl.   
      
   Also some of the example usage for pktheader creation is calling   
   perl from a bash script using bash's internal echo to farm out   
   the variables to perl's pack() function.  I also can do the same   
   with ascii2binary and eliminate the need for perl but thought I'd   
   enjoy comparing and contrasting given the mixed types of the input.   
   For the record perl's pack is 3 milliseconds faster than ascii2binary   
   doing that specific job.  Both are obtaining the data from bash's echo.   
   In the lean department ascii2binary wins and there are absolutely zero   
   modules for it which makes it far more attractive as a tool for size   
   restrictive enviroments and the end result, a pktheader in this case,   
   is exactly the same no matter which call is made from bash.   
      
   Depending on the goal, I don't think 3 milliseconds is that big of a   
   price to pay but given that I require perl, as well as a few of it's   
   modules (nowhere near what is provided by the basic perl package), then   
   it is likely that the bash call to perl's pack() just might survive.   
   I am currently using it to post this message to an outbound packet.   
      
   Life is good,   
   Maurice   
      
   --- GNU bash, version 4.2.10(2)-release (x86_64-core2-linux-gnu)   
    * Origin: Pointy Stick Society (1:261/38.9)