Bug #38474 for Unix-Lsof: unwanted error output when 'lsof' binary not found in $PATH

Thu Aug 14 07:27:21 2008 riccardomurri [...] yahoo.it - Ticket created

Subject:

unwanted error output when 'lsof' binary not found in $PATH

Hello, Whne the 'lsof' binary is not found in $PATH, use of Unix::Lsof::lsof prints some unwanted lines to STDERR:: $ type lsof -bash: type: lsof: not found $ perl -e 'use Unix::Lsof; $lsof=lsof("-i");' Use of uninitialized value in -e at /usr/perl5/site_perl/5.8.4/Unix/Lsof.pm line 62. Use of uninitialized value in concatenation (.) or string at /usr/perl5/site_perl/5.8.4/Unix/Lsof.pm line 63. Cannot find lsof program : No such file or directory at /usr/perl5/site_perl/5.8.4/Unix/Lsof.pm line 63. There are a couple of issues here: 1) the "Use of uninitialized value ..." which should not happen 2) I'd like an option to make Unix::Lsof totally silent: when using Unix::Lsof for writing application plugins, output should often be formatted in a pre-defined way: it is the caller responsibility to read the error from $lsof->errors() and (eventually) print it. Thanks! Regards, Riccardo

Wed Aug 20 11:47:29 2008 MARCB [...] cpan.org - Correspondence added

Hi Riccardo, thank you for your bug report! I agree to 1.), those warnings should not occur and will be gone in the soon-to-be-released 0.0.3. However, with 2.) I'm not quite so convinced. Writing plugins that do not expect any output even for a catastrophic failure seems a fairly specialised use case, and you could always do eval { lsof(...); } and examine the output of $@ as well as $lsof->errors . Any reason why the above isn't a good solution for you? I'm not ruling out such an option entirely (it would probably be called "suppress_fatals" and simply append fatal errors to $lsof->errors), but at the moment I'm not convinced it's needed or a good idea. Cheers, Marc

Wed Aug 20 11:47:59 2008 The RT System itself - Status changed from 'new' to 'open'

Wed Aug 20 11:48:39 2008 MARCB [...] cpan.org - Taken

Fri Aug 22 06:40:33 2008 riccardomurri [...] yahoo.it - Correspondence added

Subject:	Re: [rt.cpan.org #38474] unwanted error output when 'lsof' binary not found in $PATH
Date:	Fri, 22 Aug 2008 12:39:54 +0200
To:	bug-Unix-Lsof [...] rt.cpan.org
From:	"Riccardo Murri" <riccardomurri [...] yahoo.it>

Hi Marc, thank you for your response! Reply inline below: On Wed, Aug 20, 2008 at 5:48 PM, MARCB via RT <bug-Unix-Lsof@rt.cpan.org> wrote: Show quoted text

> However, with 2.) I'm not quite so convinced. Writing plugins that do > not expect any output even for a catastrophic failure seems a fairly > specialised use case, and you could always do > > eval { > lsof(...); > } > > and examine the output of $@ as well as $lsof->errors . > > Any reason why the above isn't a good solution for you?

It's a good solution indeed - part 2) of the report is really more of a "nice-to-have" item: having the "suppress_fatals" behaviour would, IMO, lead to cleaner code. Compare: $lr = lsof(..., suppress_fatals => 1); my_abort_function($lr->errors()) if $lr->has_errors(); with: eval { $lr = lsof(...); }; my_abort_function($@) if $@; my_abort_function($lr->errors()) if $lr->has_errors(); Anyhow, the "eval {...}" thingy is perfectly good for me, if you choose to keep Unix::Lsof that way. Cheers, Riccardo -- Riccardo Murri, via Rossée 17, 6987 Caslano (CH)

Tue Aug 26 07:16:23 2008 MARCB [...] cpan.org - Fixed in v0.0.3 added

Tue Aug 26 07:16:59 2008 MARCB [...] cpan.org - Correspondence added

Fixed on 0.0.3, added an option for error suppression

Tue Aug 26 07:17:03 2008 MARCB [...] cpan.org - Status changed from 'open' to 'resolved'