Barbie wrote: > On Fri, Oct 05, 2007 at 08:46:13AM -0400, David Golden wrote: >> I might be able to build that kind of a kill as a parameter to Tee -- >> if the tee file exceeds a certain size, then kill the process. But >> even that might require some real work to be portable. Forks and >> timeouts are not the nicest stuff to work with on Win32. > Don't go there, there be dragons!
It wouldn't be the first time a module had had OS-specific features. In this case, "if you're on Unix you can ...". For extra super special fun, make it portable to VMS :-) > This was another suggested report type I had several years ago. WARNING. > Although the distribution passes, a report is produced and sent to the > author, as per a FAIL report. It would still count as a PASS, but the > author would get the benefit of being alerted to any warnings that they > may not have been aware of. I like this a lot. We'd need to do a 'dry run' with WARNINGs *not* going to authors first though, to see how many false positives it creates. And yes, I'm sure it would need CPAN.pm changes *if you want to detect warnings*, but I suggest that anything sent to STDERR (which includes warnings) is Bad and should result in a WARNING email, because the ERR in STDERR means *error*. Using it correctly indicates that an error occured and the author should be told. If an author uses STDERR for anything that's not an error, that is itself an error, and the author should be told. That should simplify matters a little! > When I was testing I did get a few distributions that resulted in plenty > of output, mostly from annoying distributions that insisted that you > enter an value interactively on which subject, tests which use Curses must die. -- David Cantrell | Nth greatest programmer in the world Today's previously unreported paraphilia is tomorrow's Internet sensation
