Michael G Schwern
schwern at pobox.com
Thu Apr 17 18:59:32 UTC 2008
>> 'strict' but I've just committed a change to T::H that adds an
>> ignore_exit option at various places (at the request of the Parrot
>> folks) and it seems that it'd be useful to support
>> pragma +ignore_exit
>> so that a script that knew it couldn't control its exit status could
>> tell the parser to ignore it.
>> Do we like that?
> I do like the syntax, but can you give a use case here? I could
> imagine the harness wanting to ignore exit codes if it cannot reliably
> determine them (reading TAP from an archive), but I'm unclear about the
> producer directing this. However, even the slightest use case is
I'm sorta neutral on the whole idea, I haven't really thought it through or if
it's a good idea or what the pragmas or syntax should be. strict TAP and
ignoring the exit code do seem tempting.
I do agree that the producer should be able to control pragmas as the test
author knows best whether or not their test can produce strict TAP or if the
exit code should be ignored.
The user running the parser could also tell the parser to turn on pragmas, but
that would be the user making assumptions about the tests.
One thought... rather than just ignoring the exit code entirely, might it be
better to instead redefine what is an ok exit? I'm just thinking that if,
say, your test program passes with an exit of 1 that it might be handy to
still guard against segfaults. This is particularly handy for segfaults on
process cleanup, after all test results have been printed.
> That being said, I'm not entirely sure I like that test success/failure
> is dependent on exit codes as that's "out of band" information.
Remember, we're working on bringing that into band.
Defender of Lexical Encapsulation
More information about the tap-l