Re: [log4perl-devel] redirect system command STDERR to log4perl

2007-11-26 Thread John Dunbar
ok, this seems to be the best:
system("command 2>/tmp/stderr.out 1>/tmp/stdout.out");

is there any recommended way how to directly read these files with
log4perl? I would like to append the output directly to output of
logger.

On Nov 22, 2007 12:54 AM, Kevin M. Goess <[EMAIL PROTECTED]> wrote:
> John Dunbar wrote:
> > Kevin, thank you for comprehensive reply.
> >
> >> Well, the safest and most direct way would be to replace/augment all the
> >> prints to STDERR (like "warn" and "die") inside your script with
> >> log4perl logger calls.
> >
> > I would prefer this solution, but how can I the redirect whole output
> > (or STDERR atleast) of the external command to die?
> > I am almost perl beginner, sorry, if this question is too easy.
>
> Sorry, I was assuming that this external command was perl code you had
> written.  If it's some other command you don't have access to, then you
> can either wrap it in perl and use temp files to capture the output
>
>my $stdout = `command 2>/tmp/securetempfile`;
>
> or
>system("command 2>/tmp/stderr.out 1>/tmp/stdout.out");
>
> (but use File::Temp to create the tempfile names, and keep in mind that
> the tempfiles can be accessed by anyone on that machine).
>
>
> >> Or you could pipe the output of your script to another script that reads
> >> STDIN and implements logging like this:
> >>
> >>  command 2>&1 | perl -e 'use Log::Log4perl qw/:easy/; \
> >>  Log::Log4perl::easy_init($INFO);  \
> >>  while (){INFO $_}'
> >
> > Can I do this in perl script directly?
> >
> >use Log::Log4perl qw/:easy/;
> >Log::Log4perl::easy_init($INFO);
> >$pid = open(STDIN, "ls nonsense 2>/dev/null |");
> >while (){INFO $_};
>
> See above with the backticks or the system call.
>
> > Is there any way how to redirect STDOUT to INFO and STDERR to ERROR?
> > If both is not possible, STDERROR to ERROR is more important.
>
> The tempfiles is a hacky but fairly reliable way to do it.  See also
> IPC::Open3, where you can get the stdout and stderr of your child
> process on differen handles.
>

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel


[log4perl-devel] Problems with uninitialized root-logger in log::log4perl

2007-11-26 Thread Johannes Kilian
Hi,

I've encounterd a view problems with "uninitialized root-logger" log-log4perl 
(currently using Version1.12):

System:
ActiveStatePerl 5.8.8.817
WinXP SP2
Log::Log4Perl 1.12

Using my "traditional" log4perl configuration file (used from 0.51 on) the 1.12 
Version shows following behaviour (which I didn't notice with earlier versions 
...):
1.) Initializing log4perl works without any errors
2.) Getting loggers works without any errors
3.) Using $logger->logdie(...) (and other functions dieing, like 
$logger->error_die(...)) makes the program die IMMEDIATELY; I'm not able to 
catch the die-exception within an eval{} block -> WHY??? - I'm sure it worked 
with earlier versions of log4perl ..
4.) Finishing my program an error from log4perl occurs: (in cleanup) 
Internal error: Root Logger not initialized. at 
C:/Programme/Perl/site/lib/Log/Log4perl/Logger.pm line 557 during global 
destruction.

What's going on? What can I do to make $logger->logdie(...)  to be catchable 
with eval{} again?

Any help welcome ...

Johannes

As an appendix, my Log4perl-configuration (quite complex):



http://log4perl.sourceforge.net/";
threshold="debug"
oneMessagePerAppender="true">




  
  
  
  
  

  


  
  
  
  
  

  


  
  

  


  
  
  
  
  

  


  
  
  
  
  

  



  





  
  
  


  
  
  


  
  
  





  
  
  
  



  
  


  
  


  
  


  
  





-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel


[log4perl-devel] Log::Log4Perl::Util::module_available broken...

2007-11-26 Thread Merijn Broeren
Hello,

There is an existing RT bug for the issue of module_available being
broken already:

http://rt.cpan.org/Public/Bug/Display.html?id=24884

which is 10 months older then the release done yesterday. Since there
have been tickets closed since then I am assuming you guys are aware of
this issue already. 

I just wanted to reiterate that this code really is broken, both in
spirit and in implementation. Please reconsider having this broken code
in such a useful package. The patch in RT is sufficient to restore
functionality, but I would personally take out all module_available
calls everywhere from Log4perl and replace it with a simple eval {require }. 

To illustrate implementation brokenness, see line 33 of Util.pm:

ref $dir !~ /^(GLOB|SCALAR|HASH|REF|LVALUE)$/) {

which tries to determine the reference status on the result of a regular
expression. I assume the author wanted to write this :

ref($dir) !~ /^(GLOB|SCALAR|HASH|REF|LVALUE)$/) {

but forgot about operator precedence. So this test will *never* be true. 
Which is good, as the code on line 34 inside the if branch is bad as well. 

return 1 if $dir->INC();

as the INC method is supposed to return the open file handle of the file
requested. Since you do not request a file, the method is under no
obligation to actually return a true value.

But it would be pointless to try fixing this implementation since
whatever the result of the module_available function is, it just leads
to an eval { require } afterwards anyway, so you are doubling the
effort. It would be very nice if you would consider to modify Log4perl
to not use module_available. Or accept the RT patch. The current code
does not work with @INC objects. 

Regards,
-- 
Merijn Broeren | We take risks, we know we take them. Therefore, when things
   | come out against us, we have no cause for complaint.
   | - Scott, last journal entry, march 1912

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
log4perl-devel mailing list
log4perl-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/log4perl-devel