Re^3: How to capture (intercept) output (warnings) of a module

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

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.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

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

Comment on Re^3: How to capture (intercept) output (warnings) of a module

Replies are listed 'Best First'.
Re^4: How to capture (intercept) output (warnings) of a module by salva (Canon) on Sep 05, 2020 at 12:15 UTC
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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^4: How to capture (intercept) output (warnings) of a module
by salva (Canon) on Sep 05, 2020 at 12:15 UTC

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.

[reply]
[d/l]
[select]