Skip Menu |

This queue is for tickets about the File-ChangeNotify CPAN distribution.

Report information
The Basics
Id: 73547
Status: rejected
Priority: 0/
Queue: File-ChangeNotify

People
Owner: Nobody in particular
Requestors: sflitman [...] xenoscience.com
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.20
Fixed in: (no value)



Subject: Dependency on IO::KQueue breaks installation on Ubuntu or Debian
This problem comes up when using File::ChangeNotify as it tries to load a subclass for BSD systems then fails. Installation is clean, and it correctly states that IO::KQueue is not available (and by the way, it does not install at all on Ubuntu/Debian) and that kqueue will be disabled. However, when a client program uses File::ChangeNotify, blammo because File::ChangeNotify::Watcher::KQueue attempts to load IO::KQueue and craps out. IO::KQueue does not install on non-BSD systems; a quick fix for this problem is to rename KQueue.pm to KQueue.pm.off in File/ChangeNotify/Watcher subdirectory, but I hate to mess with my Perl library tree. Please change the implementation to correctly disable KQueue support on systems that lack support for it. Thanks for a great module! SSF
Subject: Re: [rt.cpan.org #73547] Dependency on IO::KQueue breaks installation on Ubuntu or Debian
Date: Thu, 29 Dec 2011 00:37:59 -0600 (CST)
To: Steve Flitman via RT <bug-File-ChangeNotify [...] rt.cpan.org>
From: Dave Rolsky <autarch [...] urth.org>
On Thu, 29 Dec 2011, Steve Flitman via RT wrote: Show quoted text
> This problem comes up when using File::ChangeNotify as it tries to load > a subclass for BSD systems then fails. Installation is clean, and it > correctly states that IO::KQueue is not available (and by the way, it > does not install at all on Ubuntu/Debian) and that kqueue will be > disabled. However, when a client program uses File::ChangeNotify, > blammo because File::ChangeNotify::Watcher::KQueue attempts to load > IO::KQueue and craps out. > > IO::KQueue does not install on non-BSD systems; a quick fix for this > problem is to rename KQueue.pm to KQueue.pm.off in > File/ChangeNotify/Watcher subdirectory, but I hate to mess with my Perl > library tree. > > Please change the implementation to correctly disable KQueue support on > systems that lack support for it. Thanks for a great module!
This doesn't make any sense. The mechanism for determining what module to load ignores the failure to load IO::KQueue. I myself run Ubuntu and this module works fine. Please post some output from a program that demonstrates this problem. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/
Subject: Dependency on IO::KQueue causes runtime error on Ubuntu or Debian
From: sflitman [...] xenoscience.com
Sorry for the delay, I've been busy with other projects, then this came up on a new install for a client's Debian server. Use this script and you will see the error occurs only when client code installs a DIE handler: -------------------------------cut-------------------------------- #!/usr/bin/perl # testfcn1 - test File::ChangeNotify bug involving KQueue.pm use strict; use warnings; use File::ChangeNotify; # uncomment to see error #$SIG{__DIE__}=sub { print "$_[0]\n"; exit 0 }; my $watcher=File::ChangeNotify->instantiate_watcher( directories => [ '/tmp' ], filter => qr(\.txt$) ); while (my @events=$watcher->wait_for_events()) { for my $event (@events) { print $event->type,': ',$event->path,"\n"; } } ------------------------------cut--------------------------------- Works great on Ubuntu 11.10 for catching changes to .txt files in /tmp, but once that DIE handler is uncommented, blammo: Can't locate IO/KQueue.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.12.4 /usr/local/share/perl/5.12.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.12 /usr/share/perl/5.12 /usr/local/lib/site_perl .) at /usr/share/perl5/File/ChangeNotify/Watcher/KQueue.pm line 13. BEGIN failed--compilation aborted at /usr/share/perl5/File/ChangeNotify/Watcher/KQueue.pm line 13. Compilation failed in require at /usr/local/share/perl/5.12.4/Module/Runtime.pm line 317. at ./testfcn1 line 11 This may be a deficiency in Module::Runtime, but I'll defer that thought to your greater Perl expertise. Hope that helps, SSF
Subject: Re: [rt.cpan.org #73547] Dependency on IO::KQueue causes runtime error on Ubuntu or Debian
Date: Sat, 28 Apr 2012 17:43:10 -0500 (CDT)
To: Steve Flitman via RT <bug-File-ChangeNotify [...] rt.cpan.org>
From: Dave Rolsky <autarch [...] urth.org>
On Sat, 28 Apr 2012, Steve Flitman via RT wrote: Show quoted text
> Works great on Ubuntu 11.10 for catching changes to .txt files in /tmp, > but once that DIE handler is uncommented, blammo: > > Can't locate IO/KQueue.pm in @INC (@INC contains: /etc/perl > /usr/local/lib/perl/5.12.4 /usr/local/share/perl/5.12.4 /usr/lib/perl5 > /usr/share/perl5 /usr/lib/perl/5.12 /usr/share/perl/5.12 > /usr/local/lib/site_perl .) at > /usr/share/perl5/File/ChangeNotify/Watcher/KQueue.pm line 13. > BEGIN failed--compilation aborted at > /usr/share/perl5/File/ChangeNotify/Watcher/KQueue.pm line 13. > Compilation failed in require at > /usr/local/share/perl/5.12.4/Module/Runtime.pm line 317. > at ./testfcn1 line 11 > > This may be a deficiency in Module::Runtime, but I'll defer that thought > to your greater Perl expertise.
I think this is a case of "it hurts when I do that" so don't do that. If you look inside File::ChangeNotify it does wrap the attempt to load inside an eval block. There's really no sane way try to load a package without allowing for the possibility of an exception. $SIG{__DIE__} is a really unwieldy tool, so if you try to use it for an entire app it's going to bite you. -dave /*============================================================ http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) ============================================================*/
I agree with what Dave said, but... Usually SIG{__DIE__} is a bad idea. When someone feels he absolutely has to use it, though, the first problem reported is often like this one: some code runs an eval{...} with a __DIE__ handler and the handler fires unexpectedly. The best solution is to ditch the handler, but if you can't, the next best one is to check $^S. If it's true, then there's an eval going on, and your handler should stay out of the way. That might solve this problem. -- rjbs