While I have one hard condition that the script must be usable standalone and remain directly usable at the pipe level, turning it into a dual-nature function-library-style module that can still be invoked like a script isn't too difficult. A bit tasteless maybe: That's not a proper refactoring (rather a minor cleanup at best) plus I don't really see many programmatic advantages of 'use' over 'system' for a fairly 'slow' command.

CPAN modules are normally used as building blocks. The advantage of giving your script a functional interface is that it makes it easier to use as a building block. You currently use your script as part of a pipeline, but your callers may have other ideas about how they want to attach input and output streams to your program. By providing a routine that accepts an input and output file handle, you give your future users design options other than a system pipeline. For example, they may wish to have code that runs between the point where the input file handle is created and your routine is called. They may have a single output file handle and a family of input file handles they want to feed to your routine or vice versa.

You also make your program more portable. The system command is not available on all platforms and even if it is implemented, it may not always be possible to request a sequence of commands each piping their output into the next. See perlport for details.

Best, beth

thanx for the heads-up for q1/modulification, Beth :)

For the tcgrep-fork I started to hack on ages ago (who doesn't have a perl grep of his/her own with some special tricks :) ), I indeed recently turned it into a dual nature module. Which I yet have to use as a module... . So I might also find some time to do that for all 5 candidate scripts regardless of cpan or no cpan.

Portability other than Unix-Unix: not quite my cup of tea, with the possible exception of cygwin :>.

As for waitcond, its usable output information is basically just the return code and the fact that it exited: so pipeline in this case includes shell command sequences as well. (cmd1; waitcond...; cmd2)|cmd3. Consider a  ssh HOST make in one shell window, and using waitcond in a different shell for e.g. the tty of the ssh/make command to be idle for more than a few minutes: waitcond not recent tty /dev/pts/13; mpg123 trumpets-of-jericho; echo check for make success or early failure.... (waitcond is the worst of the bunch with its pure process/shell conception)

So let me ask a question 2b:

I've absolutely no naming idea: where in the main module hierarchies e.g. waitcond might fit. Other than maybe not signaling its dual-module/script-nature and just selecting a module hierarchy that at least somewhat matches a not entirely-impossible use case.

Sys::, Proc::, App:: ??? All of which fit (badly/way too generic).

Toplevel (but isn't that even worse)??

???

Packaging for CPAN is the best thing to do. Congratulations for your first distro!

Your release is quite clean.

Just change Build.PL to add requires for the modules used in tests: Test::More, File::Spec::Functions.

Also, your test t/waitcond.t seems quite light: you are just checking the script syntax with 'perl -c'. You may use instead a CPAN module: Test::Script. This will be more portable.

Any ideas for really testing the script execution?

Also look at the benefits of releasing your code on CPAN: your distribution has already been tested on 23 environments. With a better testsuite you'll get better feedback.

Thanx for giving it a review, dolmen. Any takers for my naming/category issue :)?

I've updated my local Build.PL's build_requires (=>0,), thanx for the tip.

(and yes, the amount of test green also surprised me)

As for the tests, I might go from really very light to just fairly light, but a realistic portable testset to be run from CPAN.pm just doesn't seem quite realistic to me:

Portability for some of waitconds functionality like iostat (diskidle) is one problem, writing a portable test for that is another, quite worse one. Plus the 30 second delay required to get something at least somewhat sane out of iostat...

Read more... (2 kB)

Btw1, is there some Perl standard distribution location for such extra stuff, to get it installed in the filesystem, but out of the way? Other than say just occupying /usr/local/share/doc/waitcond_cpan_distribution? (and anything /usr requires being root or a sudo prefix in the CPAN.pm config, something I'm also not that happy about)

q2, is there a way to add cygwin (but not pure windows) as an os for the cpan testers?

q3, my current understanding is that the tests may be automated, but the report may also be manually augmented(?) to contain some additional information and comments. Are such augmented/more valuable reports marked or filterable in some way? Or do I have to hope for the tester to fail the test, or add an email so I at least won't miss his comments/reviews?