in reply to cpan and (dual-nature) scripts?

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

Replies are listed 'Best First'.
Re^2: cpan and (dual-nature) scripts?
by jakobi (Pilgrim) on Sep 29, 2009 at 23:46 UTC

    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)??

    ???
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom