Free parse software for linux

Parse::RPN is a minimalist RPN parser/processor (a little like FORTH).

SYNOPSIS

use Parse::RPN;
$result=rpn(string ...);
@results=rpn(string ...);

$error=rpn_error();

string... is a list of RPN operator and value separated by a coma in scalar mode RPN return the result of the calculation (If the stack contain more then one element, you receive a warning and the top value on the stack) in array mode, you receive the content of the stack after evaluation

rpn() receive in entry a scalar of one or more elements coma separated and evaluate as an RPN (Reverse Polish Notation) command. The function split all elements and put in the stack. The operator are case sensitive. The operator are detect as is, if they are alone in the element of the stack. Extra space before or after are allowed (e.g "3,4,ADD" here ADD is an opeartor but it is not the case in "3,4,ADD 1") If element is not part of the predefined operator (dictionary), the element is push as a litteral.

If you would like to put a string which is part of the dictionary, put it between quote or double-quote (e.g "3,4,ADD" here ADD is a literal and the evaluation reurn ADD and a warning because the stack is not empty) If the string contain a coma, you need also to quote or double-quote the string. (be care to close your quoted or double-quoted string)

The evaluation follow the rule of RPN or FORTH or POSTCRIPT or pockect calcutor HP. Look on web for documentation about the use of RPN notation.

I use this module in a application where the final user need to create an maintain a configuration file with the possibility to do calculation on variable returned from application.

The idea of this module is comming from Math::RPN of Owen DeLong, owen@delong.com that I used for more then a year before some of my customer would like more ... I correct a bug (interversion of > and >=), add the STRING function, pattern search and some STACK functions.

rpn_error() return the last error from the evaluation (illegal division by 0, error from the PERL function execution...) each time that rpn() is call the rpn_error() is reinitianised.

MRTG::Parse is a Perl extension for parsing and utilizing the logfiles generated by the famous MRTG Tool.

SYNOPSIS

use strict;
use MRTG::Parse;

my $mrtg_logfile = "/var/www/htdocs/mrtg/eth0.log";
my $period = "day";
my $desired_unit = "GB";

my ($traffic_incoming, $traffic_outgoing, $traffic_sum) = mrtg_parse($mrtg_logfile, $period, $desired_unit);

print "Incoming Traffic: $traffic_incomingn";
print "Outgoing Traffic: $traffic_outgoingn";
print "= Sum $traffic_sumn";

This perl extension enables its users to parse and utilize the logfiles that are generated by the famous MRTG (Multi Router Traffic Grapher) tool.

mrtg_parse() takes three argument:

1st: filename of the mrtg logfile
2nd: time period to genereate the output for
valid values are:
- individual time periods like: 20040821-20050130 (ISO 8601)
- static values: day, month, year
3rd: the desired unit (optional)
valid values are:
- B, KB, MB, GB, TB
- if missing mrtg_parse will chose an adequate one for you
mrtg_parse() returns three values:

1st: Incoming traffic
2nd: Outgoing traffic
3rd: Sum of incoming and outgoing

Test::Parser is a collection of parsers for different test output file formats. These parse the data into a general purpose data structure that can then be used to create reports, do post-processing analysis, etc.

Test-Parser can also export tests in SpikeSources TRPI test description XML language.

Parse::Nibbler is Perl module to parse huge files using grammars written in pure perl.

Create a parser object using the ->new method. This method is provided by the Parse::Nibbler module and should not be overridden.

The main functionality of the Parse::Nibbler module is the Register subroutine. This subroutine is used to define the rules of your grammar. The Register subroutine takes two parameters: A string and a code reference.

The string is the name of the rule (i.e. the name of the subroutine/method)

The code reference is a reference to the code to execute for this rule.

The Register subroutine will take the code reference, wrap it up in another subroutine that acts as a closure, and then installs that code reference as a subroutine with the name matching the given string.

The wrapper code (the closure) is the same for every rule. The wrapper code handles quantifiers, calls the rule, and decides what to do based on the rule passing or failing.
A rule is a code reference with a given string name that have been passed to Register. Here is an example of a rule:
Register ( Name, sub { my $p = shift; $p->AlternateValues( Jim, Scotty, Spock );
}
);

The parser object will always be passed in as the first parameter to your rule. You must pass this into any further rules or any Parse::Nibbler methods.

In the above example, the rule, "Name" is Registered. "Name" calls one of the builtin methods, AlternateValues, defined below. Once a rule is Registered, other rules can call it:
Register ( MedicalDiagnosis, sub { my $p = shift; $p->AlternateValues("Hes", "Shes"); $p->ValueIs("dead"); $p->ValueIs(","); $p->Name; $p->ValueIs("!"); } );

This code registers a rule called "MedicalDiagnosis". It uses some builtin methods, but it also calls the rule just registered, "Name".

Once a user defines a rule, they can use it in other rules by simply calling it as they would call a method.

Rules registered with the Parse::Nibbler module can be called with quantifiers. Quantifiers are passed into the Rule when you call it in your grammar by passing in a string that matches the format described here.

Quantifiers allow you to specify the quantity of rules present. Quantifiers also allow you to specify whether multiple rules have separators.

Quantifiers are specified using the following string format:

{quantifier}

This indicates that there are zero or one Name rules expected: $p->Name({?});
This indicates that there are zero or more Name rules expected: $p->Name({*});
This indicates that there are one or more Name rules expected: $p->Name({+});
This indicates that there are exactly three Name rules expected: $p->Name({3});
This indicates there are 1 to 3 Name rules expected: $p->Name({1:3});
This indicates there are at least 2 Name rules expected: $p->Name({2:);

Separators are specified using the following string format:

/separator/

This indicates 1 or more Name rules, each separated by a comma:

$p->Name({1:}/,/);

It is the job of the Register function to make sure this additional functionality is provided transparently and automagically to you.

If you call a rule with no quantifier and no separator, the rule will assume the quantifier is 1 and there is no separator.

Additional Parse::Nibbler methods are provided to simplify rule definition and to provide smart, automatic error handling, etc. You grammars should only call other rules that you defined, or these methods explained below.

(Note: these methods do not take quantifiers)
############### Method: ValueIs ###############
Parameters: One parameter, required. A string containing the expected value.
Example: $p->ValueIs( stringvalue );
Description:
This method will look at the next lexical and determine if its value matches that of the stringvalue given as a parameter. If it does not match, an exception is raised and the rule fails.
If the values do match, then the parser stores the lexical, and the rule continues.
####################### Method: AlternateValues #######################
Parameters: A list of string parameters, at least two values.
Example: $p-AlternateValues( value1, value2 );
Description:
This method behaves like the ValueIs method, except that it will recieve a list of allowed alternate expected values. The first match that succeeds causes the rule to pass and return.
If no match occurs, then an exception is raised and the rule aborts.
If a match does occur, the parser stores the lexical, and the rule continues.
############## Method: TypeIs ##############
Parameters: One parameter, required. A string containing the expected type.
Description:
This method will look at the next lexical item, and determine if the lexical type matches the type given as a parameter.
Valid type values depend on the Lexer that you use, but possible values may include "Identifier" and "Number", etc.
Use this in a case where your rule requires an identifier type, for example, but it does not care what the name of the identifier is for the rule.
If a match occurs, the parser stores the lexical and the rule continues.
If a match does not occur, an exception is raised, and the rule aborts.
###################### Method: AlternateRules ######################
Parameters: A list of string parameters, at least two.
Example: $p->AlternateRules( Rule1, Rule2 );
Description:
You can describe rule alternation in your rule by calling this method. The method takes a list of strings whose string values match the names of the valid alternate rule names.
In the above example, the McCoy rule is either a declaration of profession or a medical diagnosis. These are two rules that are defined in the same package. The AlternateRules method allows you to define multiple rules that may be valid at the same point in the text.
If a rule in the parameter list succeeds, the AlternateRule method succeeds, and returns immediately.
If no rule succeeds, an exception is thrown, and the rule aborts.
This rule expects either a "DeclareProfession" rule or a "MedicalDiagnosis" rule to be present.
Register ( McCoy, sub { my $p = shift; $p->AlternateRules( DeclareProfession, MedicalDiagnosis ); } );
You can specify quantifiers as part of the alternate rule strings.
$p->AlternateRules( DeclareProfession({+}), MedicalDiagnosis );
The above example indicates that you can have one or more DeclareProfession rules OR ALTERNATELY you can have exactly one MedicalDiagnosis rule.

EXPORT

Register, used to register the rules in your grammar.