Looks like not the OP's (i.e. davidfilmer) case, but, sadly, libtiff shipped with Strawberry Perl generates warnings as ugly pop-up GUI modal boxes, requiring user interaction to dispose. Therefore, without recompilation, the solution with Capture::Tiny won't work.

On the other hand, libtiff provides a TIFFSetWarningHandler function just for customizing error reporting. It is not exposed by the Perl wrapper, but adding that feature shouldn't be too difficult.

Ah, then I can do it:

use strict;
use warnings;
use Graphics::TIFF;

my $fn = 'TIFF01.TIF';  # a file known to generate 
                        # a warning (as shown below)

DummyTiffLogger::init();

Graphics::TIFF-> Open( $fn, 'r' ) 
    for 1..5;

package DummyTiffLogger {

sub logMessage {
    my $s = shift;
    printf "message logged: <%s>\n", $s
}

use Inline C => Config => LIBS => '-ltiff';
use Inline C => <<'END_OF_C';

#define BUFSIZE 1024

void _log(char* m, char* fmt, va_list ap) {
    char* buf;
    int len;
    SV* sv;
    
    Newxz(buf, BUFSIZE, char);
    len = vsprintf(buf, fmt, ap);
    Renew(buf, len + 1, char);
    sv = newSV(0);
    sv_usepvn_flags(sv, buf, len, SV_SMAGIC | SV_HAS_TRAILING_NUL);

    dSP;
    ENTER;
    SAVETMPS;
    PUSHMARK(SP);
    XPUSHs(sv_2mortal(sv));
    PUTBACK;

    call_pv("DummyTiffLogger::logMessage", G_DISCARD);

    FREETMPS;
    LEAVE;
}

void init() { TIFFSetWarningHandler(&_log); }

END_OF_C
}           # package

__END__

message logged: <Unknown field with tag 32781 (0x800d) encountered>
message logged: <Unknown field with tag 32781 (0x800d) encountered>
message logged: <Unknown field with tag 32781 (0x800d) encountered>
message logged: <Unknown field with tag 32781 (0x800d) encountered>
message logged: <Unknown field with tag 32781 (0x800d) encountered>
[download]

> Perl generates warnings as ugly pop-up GUI modal boxes,

Isn't this dependent of the way Perl is started?

IOW did you have an associated DOS window or did you use wperl?

Your solution looks nice you might consider sending a patch request to the module's maintainer, such that users avoid using C.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

IOW did you have an associated DOS window or did you use wperl?

They are usual cmd.exe console window and perl.exe interpreter. Actually, GUI warnings for CLI tools was long standing issue for libtiff and Windows, e.g. link. Some defines were messed-up in C source, IIRC.

However, I'm glad to stand corrected: as I'm checking now, in Strawberry Perl 5.28.2.1 (libtiff 4.0.7), there are "ugly GUI pop-ups" for warnings with libtiff, but in 5.30.2.1 (libtiff 4.0.10) there are "proper and nice" console messages. They finally fixed it, but not very long ago.

consider sending a patch request to the module's maintainer

when/if I have patch-quality solution, not proof-of-concept/cuff-scribbles code:) If only for a reason, that Inline::C should probably be converted to XS (which I have no experience with) to match Graphics::TIFF source

But you should know better.

> libtiff provides a TIFFSetWarningHandler function just for customizing error reporting.

I've recommended this myself, but I'm not sure if this interface allows a Perl sub as call back.

°) Correction: to "bequeath", to "pass on" in correct English, "inherit" can't be used that way

I've always been under the impression that redirections are inherited to a child process.

Well, redirections are inherited by child processes... sometimes!

It depends on whether the redirection target exists at the OS level or not. In practice, that means whether a OS file descriptor is associated to the Perl file handle or not.

When you open a perl scalar as a file (as in, open my $fh, '>', \$data), no file is opened at the OS level, and no file descriptor becomes associated to the file handler. So, forked processes or just C libraries calling C stdio functions (or the OS syscalls in any other way) are not going to see it and may fail, or in the case of stderr, stdin or stdout, just use the default streams.