Re: multiple programs sharing redirected STDERR

Here is code that uses syswrite to write out warnings STDERR. This should allow multiple programs to write to the same file without the need for locking. It would also be easy to use a different file handle than STDERR to output warnings if wanted.

It is possible that this code will not work on all systems.

#!/usr/bin/perl -w
# show two concurrent processes intermingling their STDERR to the same
+ file.
# Name the program 'test_err.pl' and invoke it from command line with:
#    test_err.pl hs

use strict;

my $err_file = 'errfile.txt';
open STDERR, ">> $err_file"
    or die "cannot open initial $err_file:  $!\n";

$SIG{'__WARN__'} = sub { syswrite STDERR, $_[0] };

my $what_to_do = shift;
warn "$what_to_do hello world\n";

system( 'test_err.pl', 'abc' )
    if $what_to_do eq 'hs';

my $test_string;
warn "success\n" if $test_string eq 'xyz';

warn "$what_to_do goodbye world\n";

# Adds the following text to 'errfile.txt':
__DATA__
hs hello world
abc hello world
Use of uninitialized value in string eq at C:\aa\test_err.pl line 19.
abc goodbye world
Use of uninitialized value in string eq at C:\aa\test_err.pl line 19.
hs goodbye world
[download]

-- gam3
A picture is worth a thousand words, but takes 200K.

Comment on Re: multiple programs sharing redirected STDERR Download Code

Replies are listed 'Best First'.
Re^2: multiple programs sharing redirected STDERR via syswrite by ff (Hermit) on Apr 27, 2005 at 17:42 UTC
Okay, so the reason to use 'syswrite' is that it bypasses buffered IO, and therefore I have higher likelihood of avoiding any kind of conflict as one routine and then the next write to STDERR? And in this case '$\|' is extraneous? I noticed that documentation for 'syswrite' says it processes a single scalar parameter and that 'warn' handles a list. Yet when I broke my example's warn strings into a list of two parameters, the 'syswrite' seemed to print everything that 'warn' was given. Is it somehow scooping up all those parameters as individual scalars to 'syswrite' against? Regarding naming the filehandle differently from STDERR: If I do so won't that be misleading since all the normal STDERR-bound things like 'warn' and various warnings from the system will go to the designated filehandle, and a `print STDERR 'some warning'` would not be mixing with the other warnings? I guess it's a matter of perspective. Suppose a user opens the logfile with Notepad or vim, and does some editing. To do so while the Tk frontend of the program is open, not doing anything because the user hasn't invoked any functions recently via a widget, still sounds suboptimal since the program itself still has hooks with the logfile via the ">>" open. Within my program, when users open the file via my button (invoking Notepad or vim via a 'system' call), they can't get anything else to happen, and so my program won't be competing for the ability to write to that logfile. Is allowing users to access the subject file likely to confuse 'syswrite'? I notice that p. 813 of my Camel book says: Because `syswrite` bypasses the C standard I/O library, do not mix calls to it with reads (other than `sysread`, writes (like `print`, `printf`, or `write`, or other stdio functions like `seek`, `tell`, or `eof` unless you are into heavy wizardry.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: multiple programs sharing redirected STDERR via syswrite
by ff (Hermit) on Apr 27, 2005 at 17:42 UTC

I noticed that documentation for 'syswrite' says it processes a single scalar parameter and that 'warn' handles a list. Yet when I broke my example's warn strings into a list of two parameters, the 'syswrite' seemed to print everything that 'warn' was given. Is it somehow scooping up all those parameters as individual scalars to 'syswrite' against?

Regarding naming the filehandle differently from STDERR: If I do so won't that be misleading since all the normal STDERR-bound things like 'warn' and various warnings from the system will go to the designated filehandle, and a print STDERR 'some warning' would not be mixing with the other warnings? I guess it's a matter of perspective.

Suppose a user opens the logfile with Notepad or vim, and does some editing. To do so while the Tk frontend of the program is open, not doing anything because the user hasn't invoked any functions recently via a widget, still sounds suboptimal since the program itself still has hooks with the logfile via the ">>" open. Within my program, when users open the file via my button (invoking Notepad or vim via a 'system' call), they can't get anything else to happen, and so my program won't be competing for the ability to write to that logfile. Is allowing users to access the subject file likely to confuse 'syswrite'? I notice that p. 813 of my Camel book says:

Because syswrite bypasses the C standard I/O library, do not mix calls to it with reads (other than sysread, writes (like print, printf, or write, or other stdio functions like seek, tell, or eof unless you are into heavy wizardry.

[reply]
[d/l]
[select]