UNIX ON-LINE Man Pages - Die Onlinehilfe

Die Syntax von Unixbefehlen wird in den entsprechenden Manpages dokumentiert. Hier können Sie diese Onlinehilfe für viele Standardbefehle abrufen.

Suchoptionen:
Seiten auflisten, welche beginnen mit:
A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z   ALPHA   NUM   ANDERE   ALLE
TAP::Parser(3pm)       Perl Programmers Reference Guide       TAP::Parser(3pm)

NAME
       TAP::Parser - Parse TAP output

VERSION
       Version 3.17

SYNOPSIS
           use TAP::Parser;

           my $parser = TAP::Parser->new( { source => $source } );

           while ( my $result = $parser->next ) {
               print $result->as_string;
           }

DESCRIPTION
       "TAP::Parser" is designed to produce a proper parse of TAP output. For
       an example of how to run tests through this module, see the simple
       harnesses "examples/".

       There's a wiki dedicated to the Test Anything Protocol:

       <http://testanything.org>

       It includes the TAP::Parser Cookbook:

       <http://testanything.org/wiki/index.php/TAP::Parser_Cookbook>

METHODS
   Class Methods
       "new"

        my $parser = TAP::Parser->new(\%args);

       Returns a new "TAP::Parser" object.

       The arguments should be a hashref with one of the following keys:

       o   "source"

           This is the preferred method of passing arguments to the
           constructor.  To determine how to handle the source, the following
           steps are taken.

           If the source contains a newline, it's assumed to be a string of
           raw TAP output.

           If the source is a reference, it's assumed to be something to pass
           to the TAP::Parser::Iterator::Stream constructor. This is used
           internally and you should not use it.

           Otherwise, the parser does a "-e" check to see if the source
           exists.  If so, it attempts to execute the source and read the
           output as a stream.  This is by far the preferred method of using
           the parser.

            foreach my $file ( @test_files ) {
                my $parser = TAP::Parser->new( { source => $file } );
                # do stuff with the parser
            }

       o   "tap"

           The value should be the complete TAP output.

       o   "exec"

           If passed an array reference, will attempt to create the iterator
           by passing a TAP::Parser::Source object to
           TAP::Parser::Iterator::Source, using the array reference strings as
           the command arguments to IPC::Open3::open3:

            exec => [ '/usr/bin/ruby', 't/my_test.rb' ]

           Note that "source" and "exec" are mutually exclusive.

       The following keys are optional.

       o   "callback"

           If present, each callback corresponding to a given result type will
           be called with the result as the argument if the "run" method is
           used:

            my %callbacks = (
                test    => \&test_callback,
                plan    => \&plan_callback,
                comment => \&comment_callback,
                bailout => \&bailout_callback,
                unknown => \&unknown_callback,
            );

            my $aggregator = TAP::Parser::Aggregator->new;
            foreach my $file ( @test_files ) {
                my $parser = TAP::Parser->new(
                    {
                        source    => $file,
                        callbacks => \%callbacks,
                    }
                );
                $parser->run;
                $aggregator->add( $file, $parser );
            }

       o   "switches"

           If using a Perl file as a source, optional switches may be passed
           which will be used when invoking the perl executable.

            my $parser = TAP::Parser->new( {
                source   => $test_file,
                switches => '-Ilib',
            } );

       o   "test_args"

           Used in conjunction with the "source" option to supply a reference
           to an @ARGV style array of arguments to pass to the test program.

       o   "spool"

           If passed a filehandle will write a copy of all parsed TAP to that
           handle.

       o   "merge"

           If false, STDERR is not captured (though it is 'relayed' to keep it
           somewhat synchronized with STDOUT.)

           If true, STDERR and STDOUT are the same filehandle.  This may cause
           breakage if STDERR contains anything resembling TAP format, but
           does allow exact synchronization.

           Subtleties of this behavior may be platform-dependent and may
           change in the future.

       o   "source_class"

           This option was introduced to let you easily customize which source
           class the parser should use.  It defaults to TAP::Parser::Source.

           See also "make_source".

       o   "perl_source_class"

           This option was introduced to let you easily customize which perl
           source class the parser should use.  It defaults to
           TAP::Parser::Source::Perl.

           See also "make_perl_source".

       o   "grammar_class"

           This option was introduced to let you easily customize which
           grammar class the parser should use.  It defaults to
           TAP::Parser::Grammar.

           See also "make_grammar".

       o   "iterator_factory_class"

           This option was introduced to let you easily customize which
           iterator factory class the parser should use.  It defaults to
           TAP::Parser::IteratorFactory.

           See also "make_iterator".

       o   "result_factory_class"

           This option was introduced to let you easily customize which result
           factory class the parser should use.  It defaults to
           TAP::Parser::ResultFactory.

           See also "make_result".

   Instance Methods
       "next"

         my $parser = TAP::Parser->new( { source => $file } );
         while ( my $result = $parser->next ) {
             print $result->as_string, "\n";
         }

       This method returns the results of the parsing, one result at a time.
       Note that it is destructive.  You can't rewind and examine previous
       results.

       If callbacks are used, they will be issued before this call returns.

       Each result returned is a subclass of TAP::Parser::Result.  See that
       module and related classes for more information on how to use them.

       "run"

         $parser->run;

       This method merely runs the parser and parses all of the TAP.

       "make_source"

       Make a new TAP::Parser::Source object and return it.  Passes through
       any arguments given.

       The "source_class" can be customized, as described in "new".

       "make_perl_source"

       Make a new TAP::Parser::Source::Perl object and return it.  Passes
       through any arguments given.

       The "perl_source_class" can be customized, as described in "new".

       "make_grammar"

       Make a new TAP::Parser::Grammar object and return it.  Passes through
       any arguments given.

       The "grammar_class" can be customized, as described in "new".

       "make_iterator"

       Make a new TAP::Parser::Iterator object using the parser's
       TAP::Parser::IteratorFactory, and return it.  Passes through any
       arguments given.

       The "iterator_factory_class" can be customized, as described in "new".

       "make_result"

       Make a new TAP::Parser::Result object using the parser's
       TAP::Parser::ResultFactory, and return it.  Passes through any
       arguments given.

       The "result_factory_class" can be customized, as described in "new".

INDIVIDUAL RESULTS
       If you've read this far in the docs, you've seen this:

           while ( my $result = $parser->next ) {
               print $result->as_string;
           }

       Each result returned is a TAP::Parser::Result subclass, referred to as
       result types.

   Result types
       Basically, you fetch individual results from the TAP.  The six types,
       with examples of each, are as follows:

       o   Version

            TAP version 12

       o   Plan

            1..42

       o   Pragma

            pragma +strict

       o   Test

            ok 3 - We should start with some foobar!

       o   Comment

            # Hope we don't use up the foobar.

       o   Bailout

            Bail out!  We ran out of foobar!

       o   Unknown

            ... yo, this ain't TAP! ...

       Each result fetched is a result object of a different type.  There are
       common methods to each result object and different types may have
       methods unique to their type.  Sometimes a type method may be
       overridden in a subclass, but its use is guaranteed to be identical.

   Common type methods
       "type"

       Returns the type of result, such as "comment" or "test".

       "as_string"

       Prints a string representation of the token.  This might not be the
       exact output, however.  Tests will have test numbers added if not
       present, TODO and SKIP directives will be capitalized and, in general,
       things will be cleaned up.  If you need the original text for the
       token, see the "raw" method.

       "raw"

       Returns the original line of text which was parsed.

       "is_plan"

       Indicates whether or not this is the test plan line.

       "is_test"

       Indicates whether or not this is a test line.

       "is_comment"

       Indicates whether or not this is a comment. Comments will generally
       only appear in the TAP stream if STDERR is merged to STDOUT. See the
       "merge" option.

       "is_bailout"

       Indicates whether or not this is bailout line.

       "is_yaml"

       Indicates whether or not the current item is a YAML block.

       "is_unknown"

       Indicates whether or not the current line could be parsed.

       "is_ok"

         if ( $result->is_ok ) { ... }

       Reports whether or not a given result has passed.  Anything which is
       not a test result returns true.  This is merely provided as a
       convenient shortcut which allows you to do this:

        my $parser = TAP::Parser->new( { source => $source } );
        while ( my $result = $parser->next ) {
            # only print failing results
            print $result->as_string unless $result->is_ok;
        }

   "plan" methods
        if ( $result->is_plan ) { ... }

       If the above evaluates as true, the following methods will be available
       on the $result object.

       "plan"

         if ( $result->is_plan ) {
            print $result->plan;
         }

       This is merely a synonym for "as_string".

       "directive"

        my $directive = $result->directive;

       If a SKIP directive is included with the plan, this method will return
       it.

        1..0 # SKIP: why bother?

       "explanation"

        my $explanation = $result->explanation;

       If a SKIP directive was included with the plan, this method will return
       the explanation, if any.

   "pragma" methods
        if ( $result->is_pragma ) { ... }

       If the above evaluates as true, the following methods will be available
       on the $result object.

       "pragmas"

       Returns a list of pragmas each of which is a + or - followed by the
       pragma name.

   "commment" methods
        if ( $result->is_comment ) { ... }

       If the above evaluates as true, the following methods will be available
       on the $result object.

       "comment"

         if ( $result->is_comment ) {
             my $comment = $result->comment;
             print "I have something to say:  $comment";
         }

   "bailout" methods
        if ( $result->is_bailout ) { ... }

       If the above evaluates as true, the following methods will be available
       on the $result object.

       "explanation"

         if ( $result->is_bailout ) {
             my $explanation = $result->explanation;
             print "We bailed out because ($explanation)";
         }

       If, and only if, a token is a bailout token, you can get an
       "explanation" via this method.  The explanation is the text after the
       mystical "Bail out!" words which appear in the tap output.

   "unknown" methods
        if ( $result->is_unknown ) { ... }

       There are no unique methods for unknown results.

   "test" methods
        if ( $result->is_test ) { ... }

       If the above evaluates as true, the following methods will be available
       on the $result object.

       "ok"

         my $ok = $result->ok;

       Returns the literal text of the "ok" or "not ok" status.

       "number"

         my $test_number = $result->number;

       Returns the number of the test, even if the original TAP output did not
       supply that number.

       "description"

         my $description = $result->description;

       Returns the description of the test, if any.  This is the portion after
       the test number but before the directive.

       "directive"

         my $directive = $result->directive;

       Returns either "TODO" or "SKIP" if either directive was present for a
       test line.

       "explanation"

         my $explanation = $result->explanation;

       If a test had either a "TODO" or "SKIP" directive, this method will
       return the accompanying explantion, if present.

         not ok 17 - 'Pigs can fly' # TODO not enough acid

       For the above line, the explanation is not enough acid.

       "is_ok"

         if ( $result->is_ok ) { ... }

       Returns a boolean value indicating whether or not the test passed.
       Remember that for TODO tests, the test always passes.

       Note:  this was formerly "passed".  The latter method is deprecated and
       will issue a warning.

       "is_actual_ok"

         if ( $result->is_actual_ok ) { ... }

       Returns a boolean value indicating whether or not the test passed,
       regardless of its TODO status.

       Note:  this was formerly "actual_passed".  The latter method is
       deprecated and will issue a warning.

       "is_unplanned"

         if ( $test->is_unplanned ) { ... }

       If a test number is greater than the number of planned tests, this
       method will return true.  Unplanned tests will always return false for
       "is_ok", regardless of whether or not the test "has_todo" (see
       TAP::Parser::Result::Test for more information about this).

       "has_skip"

         if ( $result->has_skip ) { ... }

       Returns a boolean value indicating whether or not this test had a SKIP
       directive.

       "has_todo"

         if ( $result->has_todo ) { ... }

       Returns a boolean value indicating whether or not this test had a TODO
       directive.

       Note that TODO tests always pass.  If you need to know whether or not
       they really passed, check the "is_actual_ok" method.

       "in_todo"

         if ( $parser->in_todo ) { ... }

       True while the most recent result was a TODO. Becomes true before the
       TODO result is returned and stays true until just before the next non-
       TODO test is returned.

TOTAL RESULTS
       After parsing the TAP, there are many methods available to let you dig
       through the results and determine what is meaningful to you.

   Individual Results
       These results refer to individual tests which are run.

       "passed"

        my @passed = $parser->passed; # the test numbers which passed
        my $passed = $parser->passed; # the number of tests which passed

       This method lets you know which (or how many) tests passed.  If a test
       failed but had a TODO directive, it will be counted as a passed test.

       "failed"

        my @failed = $parser->failed; # the test numbers which failed
        my $failed = $parser->failed; # the number of tests which failed

       This method lets you know which (or how many) tests failed.  If a test
       passed but had a TODO directive, it will NOT be counted as a failed
       test.

       "actual_passed"

        # the test numbers which actually passed
        my @actual_passed = $parser->actual_passed;

        # the number of tests which actually passed
        my $actual_passed = $parser->actual_passed;

       This method lets you know which (or how many) tests actually passed,
       regardless of whether or not a TODO directive was found.

       "actual_ok"

       This method is a synonym for "actual_passed".

       "actual_failed"

        # the test numbers which actually failed
        my @actual_failed = $parser->actual_failed;

        # the number of tests which actually failed
        my $actual_failed = $parser->actual_failed;

       This method lets you know which (or how many) tests actually failed,
       regardless of whether or not a TODO directive was found.

       "todo"

        my @todo = $parser->todo; # the test numbers with todo directives
        my $todo = $parser->todo; # the number of tests with todo directives

       This method lets you know which (or how many) tests had TODO
       directives.

       "todo_passed"

        # the test numbers which unexpectedly succeeded
        my @todo_passed = $parser->todo_passed;

        # the number of tests which unexpectedly succeeded
        my $todo_passed = $parser->todo_passed;

       This method lets you know which (or how many) tests actually passed but
       were declared as "TODO" tests.

       "todo_failed"

         # deprecated in favor of 'todo_passed'.  This method was horribly misnamed.

       This was a badly misnamed method.  It indicates which TODO tests
       unexpectedly succeeded.  Will now issue a warning and call
       "todo_passed".

       "skipped"

        my @skipped = $parser->skipped; # the test numbers with SKIP directives
        my $skipped = $parser->skipped; # the number of tests with SKIP directives

       This method lets you know which (or how many) tests had SKIP
       directives.

   Pragmas
       "pragma"

       Get or set a pragma. To get the state of a pragma:

         if ( $p->pragma('strict') ) {
             # be strict
         }

       To set the state of a pragma:

         $p->pragma('strict', 1); # enable strict mode

       "pragmas"

       Get a list of all the currently enabled pragmas:

         my @pragmas_enabled = $p->pragmas;

   Summary Results
       These results are "meta" information about the total results of an
       individual test program.

       "plan"

        my $plan = $parser->plan;

       Returns the test plan, if found.

       "good_plan"

       Deprecated.  Use "is_good_plan" instead.

       "is_good_plan"

         if ( $parser->is_good_plan ) { ... }

       Returns a boolean value indicating whether or not the number of tests
       planned matches the number of tests run.

       Note:  this was formerly "good_plan".  The latter method is deprecated
       and will issue a warning.

       And since we're on that subject ...

       "tests_planned"

         print $parser->tests_planned;

       Returns the number of tests planned, according to the plan.  For
       example, a plan of '1..17' will mean that 17 tests were planned.

       "tests_run"

         print $parser->tests_run;

       Returns the number of tests which actually were run.  Hopefully this
       will match the number of "$parser->tests_planned".

       "skip_all"

       Returns a true value (actually the reason for skipping) if all tests
       were skipped.

       "start_time"

       Returns the time when the Parser was created.

       "end_time"

       Returns the time when the end of TAP input was seen.

       "has_problems"

         if ( $parser->has_problems ) {
             ...
         }

       This is a 'catch-all' method which returns true if any tests have
       currently failed, any TODO tests unexpectedly succeeded, or any parse
       errors occurred.

       "version"

         $parser->version;

       Once the parser is done, this will return the version number for the
       parsed TAP. Version numbers were introduced with TAP version 13 so if
       no version number is found version 12 is assumed.

       "exit"

         $parser->exit;

       Once the parser is done, this will return the exit status.  If the
       parser ran an executable, it returns the exit status of the executable.

       "wait"

         $parser->wait;

       Once the parser is done, this will return the wait status.  If the
       parser ran an executable, it returns the wait status of the executable.
       Otherwise, this mererely returns the "exit" status.

   "ignore_exit"
         $parser->ignore_exit(1);

       Tell the parser to ignore the exit status from the test when
       determining whether the test passed. Normally tests with non-zero exit
       status are considered to have failed even if all individual tests
       passed. In cases where it is not possible to control the exit value of
       the test script use this option to ignore it.

       "parse_errors"

        my @errors = $parser->parse_errors; # the parser errors
        my $errors = $parser->parse_errors; # the number of parser_errors

       Fortunately, all TAP output is perfect.  In the event that it is not,
       this method will return parser errors.  Note that a junk line which the
       parser does not recognize is "not" an error.  This allows this parser
       to handle future versions of TAP.  The following are all TAP errors
       reported by the parser:

       o   Misplaced plan

           The plan (for example, '1..5'), must only come at the beginning or
           end of the TAP output.

       o   No plan

           Gotta have a plan!

       o   More than one plan

            1..3
            ok 1 - input file opened
            not ok 2 - first line of the input valid # todo some data
            ok 3 read the rest of the file
            1..3

           Right.  Very funny.  Don't do that.

       o   Test numbers out of sequence

            1..3
            ok 1 - input file opened
            not ok 2 - first line of the input valid # todo some data
            ok 2 read the rest of the file

           That last test line above should have the number '3' instead of
           '2'.

           Note that it's perfectly acceptable for some lines to have test
           numbers and others to not have them.  However, when a test number
           is found, it must be in sequence.  The following is also an error:

            1..3
            ok 1 - input file opened
            not ok - first line of the input valid # todo some data
            ok 2 read the rest of the file

           But this is not:

            1..3
            ok  - input file opened
            not ok - first line of the input valid # todo some data
            ok 3 read the rest of the file

       "get_select_handles"

       Get an a list of file handles which can be passed to "select" to
       determine the readiness of this parser.

       "delete_spool"

       Delete and return the spool.

         my $fh = $parser->delete_spool;

CALLBACKS
       As mentioned earlier, a "callback" key may be added to the
       "TAP::Parser" constructor. If present, each callback corresponding to a
       given result type will be called with the result as the argument if the
       "run" method is used. The callback is expected to be a subroutine
       reference (or anonymous subroutine) which is invoked with the parser
       result as its argument.

        my %callbacks = (
            test    => \&test_callback,
            plan    => \&plan_callback,
            comment => \&comment_callback,
            bailout => \&bailout_callback,
            unknown => \&unknown_callback,
        );

        my $aggregator = TAP::Parser::Aggregator->new;
        foreach my $file ( @test_files ) {
            my $parser = TAP::Parser->new(
                {
                    source    => $file,
                    callbacks => \%callbacks,
                }
            );
            $parser->run;
            $aggregator->add( $file, $parser );
        }

       Callbacks may also be added like this:

        $parser->callback( test => \&test_callback );
        $parser->callback( plan => \&plan_callback );

       The following keys allowed for callbacks. These keys are case-
       sensitive.

       o   "test"

           Invoked if "$result->is_test" returns true.

       o   "version"

           Invoked if "$result->is_version" returns true.

       o   "plan"

           Invoked if "$result->is_plan" returns true.

       o   "comment"

           Invoked if "$result->is_comment" returns true.

       o   "bailout"

           Invoked if "$result->is_unknown" returns true.

       o   "yaml"

           Invoked if "$result->is_yaml" returns true.

       o   "unknown"

           Invoked if "$result->is_unknown" returns true.

       o   "ELSE"

           If a result does not have a callback defined for it, this callback
           will be invoked. Thus, if all of the previous result types are
           specified as callbacks, this callback will never be invoked.

       o   "ALL"

           This callback will always be invoked and this will happen for each
           result after one of the above callbacks is invoked.  For example,
           if Term::ANSIColor is loaded, you could use the following to color
           your test output:

            my %callbacks = (
                test => sub {
                    my $test = shift;
                    if ( $test->is_ok && not $test->directive ) {
                        # normal passing test
                        print color 'green';
                    }
                    elsif ( !$test->is_ok ) {    # even if it's TODO
                        print color 'white on_red';
                    }
                    elsif ( $test->has_skip ) {
                        print color 'white on_blue';

                    }
                    elsif ( $test->has_todo ) {
                        print color 'white';
                    }
                },
                ELSE => sub {
                    # plan, comment, and so on (anything which isn't a test line)
                    print color 'black on_white';
                },
                ALL => sub {
                    # now print them
                    print shift->as_string;
                    print color 'reset';
                    print "\n";
                },
            );

       o   "EOF"

           Invoked when there are no more lines to be parsed. Since there is
           no accompanying TAP::Parser::Result object the "TAP::Parser" object
           is passed instead.

TAP GRAMMAR
       If you're looking for an EBNF grammar, see TAP::Parser::Grammar.

BACKWARDS COMPATABILITY
       The Perl-QA list attempted to ensure backwards compatability with
       Test::Harness.  However, there are some minor differences.

   Differences
       o   TODO plans

           A little-known feature of Test::Harness is that it supported TODO
           lists in the plan:

            1..2 todo 2
            ok 1 - We have liftoff
            not ok 2 - Anti-gravity device activated

           Under Test::Harness, test number 2 would pass because it was listed
           as a TODO test on the plan line. However, we are not aware of
           anyone actually using this feature and hard-coding test numbers is
           discouraged because it's very easy to add a test and break the test
           number sequence. This makes test suites very fragile. Instead, the
           following should be used:

            1..2
            ok 1 - We have liftoff
            not ok 2 - Anti-gravity device activated # TODO

       o   'Missing' tests

           It rarely happens, but sometimes a harness might encounter 'missing
           tests:

            ok 1
            ok 2
            ok 15
            ok 16
            ok 17

           Test::Harness would report tests 3-14 as having failed. For the
           "TAP::Parser", these tests are not considered failed because
           they've never run. They're reported as parse failures (tests out of
           sequence).

SUBCLASSING
       If you find you need to provide custom functionality (as you would have
       using Test::Harness::Straps), you're in luck: "TAP::Parser" and friends
       are designed to be easily subclassed.

       Before you start, it's important to know a few things:

       1.
         All "TAP::*" objects inherit from TAP::Object.

       2.
         Most "TAP::*" classes have a SUBCLASSING section to guide you.

       3.
         Note that "TAP::Parser" is designed to be the central 'maker' - ie:
         it is responsible for creating new objects in the "TAP::Parser::*"
         namespace.

         This makes it possible for you to have a single point of configuring
         what subclasses should be used, which in turn means that in many
         cases you'll find you only need to sub-class one of the parser's
         components.

       4.
         By subclassing, you may end up overriding undocumented methods.
         That's not a bad thing per se, but be forewarned that undocumented
         methods may change without warning from one release to the next - we
         cannot guarantee backwards compatability.  If any documented method
         needs changing, it will be deprecated first, and changed in a later
         release.

   Parser Components
       Sources

       A TAP parser consumes input from a source.  There are currently two
       types of sources: TAP::Parser::Source for general non-perl commands,
       and TAP::Parser::Source::Perl.  You can subclass both of them.  You'll
       need to customize your parser by setting the "source_class" &
       "perl_source_class" parameters.  See "new" for more details.

       If you need to customize the objects on creation, subclass TAP::Parser
       and override "make_source" or "make_perl_source".

       Iterators

       A TAP parser uses iterators to loop through the stream provided by the
       parser's source.  There are quite a few types of Iterators available.
       Choosing which class to use is the responsibility of the iterator
       factory.

       To create your own iterators you'll have to subclass
       TAP::Parser::IteratorFactory and TAP::Parser::Iterator.  Then you'll
       need to customize the class used by your parser by setting the
       "iterator_factory_class" parameter.  See "new" for more details.

       If you need to customize the objects on creation, subclass TAP::Parser
       and override "make_iterator".

       Results

       A TAP parser creates TAP::Parser::Results as it iterates through the
       input stream.  There are quite a few result types available; choosing
       which class to use is the responsibility of the result factory.

       To create your own result types you have two options:

       option 1
         Subclass TAP::Parser::Result and register your new result type/class
         with the default TAP::Parser::ResultFactory.

       option 2
         Subclass TAP::Parser::ResultFactory itself and implement your own
         TAP::Parser::Result creation logic.  Then you'll need to customize
         the class used by your parser by setting the "result_factory_class"
         parameter.  See "new" for more details.

       If you need to customize the objects on creation, subclass TAP::Parser
       and override "make_result".

       Grammar

       TAP::Parser::Grammar is the heart of the parser - it tokenizes the TAP
       input stream and produces results.  If you need to customize its
       behaviour you should probably familiarize yourself with the source
       first.  Enough lecturing.

       Subclass TAP::Parser::Grammar and customize your parser by setting the
       "grammar_class" parameter.  See "new" for more details.

       If you need to customize the objects on creation, subclass TAP::Parser
       and override "make_grammar"

ACKNOWLEDGEMENTS
       All of the following have helped. Bug reports, patches, (im)moral
       support, or just words of encouragement have all been forthcoming.

       o   Michael Schwern

       o   Andy Lester

       o   chromatic

       o   GEOFFR

       o   Shlomi Fish

       o   Torsten Schoenfeld

       o   Jerry Gay

       o   Aristotle

       o   Adam Kennedy

       o   Yves Orton

       o   Adrian Howard

       o   Sean & Lil

       o   Andreas J. Koenig

       o   Florian Ragwitz

       o   Corion

       o   Mark Stosberg

       o   Matt Kraai

       o   David Wheeler

       o   Alex Vandiver

AUTHORS
       Curtis "Ovid" Poe <ovid@cpan.org>

       Andy Armstong <andy@hexten.net>

       Eric Wilhelm @ <ewilhelm at cpan dot org>

       Michael Peters <mpeters at plusthree dot com>

       Leif Eriksen <leif dot eriksen at bigpond dot com>

       Steve Purkis <spurkis@cpan.org>

       Nicholas Clark <nick@ccl4.org>

BUGS
       Please report any bugs or feature requests to
       "bug-test-harness@rt.cpan.org", or through the web interface at
       http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-Harness
       <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Test-Harness>.  We will
       be notified, and then you'll automatically be notified of progress on
       your bug as we make changes.

       Obviously, bugs which include patches are best. If you prefer, you can
       patch against bleed by via anonymous checkout of the latest version:

        svn checkout http://svn.hexten.net/tapx

COPYRIGHT & LICENSE
       Copyright 2006-2008 Curtis "Ovid" Poe, all rights reserved.

       This program is free software; you can redistribute it and/or modify it
       under the same terms as Perl itself.

perl v5.12.1                      2010-04-26                  TAP::Parser(3pm)
 

Scannen Sie den Barcode um die Webseite zu öffnen


Quelle: http://www.trinler.net/de/service/doc/linux/man.html?command=TAP%3A%3AParser
Gedruckt am: 22.08.2017 16:43 GMT+0200 (2017-08-22T16:43:25+02:00)