Provided by: libtest-trap-perl_0.3.3-1_all bug

NAME

       Test::Trap::Builder::SystemSafe - "Safe" capture strategies using File::Temp

VERSION

       Version 0.3.3

DESCRIPTION

       This module provides capture strategies systemsafe, based on File::Temp, for the trap's
       output layers.  These strategies insists on reopening the output file handles with the
       same descriptors, and therefore, unlike Test::Trap::Builder::TempFile and
       Test::Trap::Builder::PerlIO, is able to trap output from forked-off processes, including
       system().

       The import accepts a name (as a string; default systemsafe) and options (as a hashref; by
       default empty), and registers a capture strategy with that name and a variant
       implementation based on the options.

       Note that you may specify different strategies for each output layer on the trap.

       See also Test::Trap (:stdout and :stderr) and Test::Trap::Builder (output_layer).

OPTIONS

       The following options are recognized:

   preserve_io_layers
       A boolean, indicating whether to apply to the handles writing to and reading from the
       tempfile, the same perlio layers as are found on the to-be-trapped output handle.

   io_layers
       A colon-separated string representing perlio layers to be applied to the handles writing
       to and reading from the tempfile.

       If the preserve_io_layers option is set, these perlio layers will be applied on top of the
       original (preserved) perlio layers.

CAVEATS

       Using File::Temp, we need privileges to create tempfiles.

       We need disk space for the output of every trap (it should clean up after the trap is
       sprung).

       Disk access may be slow -- certainly compared to the in-memory files of PerlIO.

       If the file handle we try to trap using this strategy is on an in-memory file, it would
       not be available to other processes in any case.  Rather than change the semantics of the
       trapped code or silently fail to trap output from forked-off processes, we just raise an
       exception in this case.

       If there is another file handle with the same descriptor (f ex after an "open OTHER,
       '>&=', THIS"), we can't get that file descriptor.  Rather than silently fail, we again
       raise an exception.

       If the options specify (explicitly or via preserve on handles with) perlio custom layers,
       they may (or may not) fail to apply to the tempfile read and write handles.

       Threads?  No idea.  It might even work correctly.

BUGS

       Please report any bugs or feature requests directly to the author.

AUTHOR

       Eirik Berg Hanssen, "<ebhanssen@cpan.org>"

COPYRIGHT & LICENSE

       Copyright 2006-2014 Eirik Berg Hanssen, All Rights Reserved.

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