David Christensen writes: > On 08/31/12 07:53, Leon Timmermans wrote: > > >Why do you want to do this? > > So that after "make install" my Perl scripts can say "use MyModulino" > and I can invoke the modulino from the command line via "mymodulino > ARGS".
Yes, but why do you want to do _that_? It's fairly unusually for a piece of code to be appropriate both as a stand-alone program and as a module loaded by other programs. For instance, the situations often have different interfaces: a program may take command-line arguments, but a module's arguments are supplied in its use line. It is of course possible to do both in one file, and have an if test to work out which way the file is being invoked, then provide a commandy interface for a moduley interface as appropriate. But that makes things hard for yourself, increasing complexity. There's the complexity you're asking about here (forcing a single file to act as both a command and a module) and additional complexity in the file (divining which invocation mode has been used, and acting accordingly). A simpler way, and indeed the usual way with these sort of Perl modules, is to have two separate files: * Put the module in a normal module file, with a module interface. * Have a wrapper program in a separate command file. This uses the module in the first file. It can parse command-line arguments or do anything which is command-specific, before invoking the module using its module interface. That way there's nothing awkward going on, in either the installation or the file itself. Examples on Cpan of commands doing something like this: https://metacpan.org/module/meta https://metacpan.org/module/ack https://metacpan.org/module/GAAS/libwww-perl-6.04/bin/lwp-request Would an approach like that work for your situation? If not, can you share a few details on what makes your module different, so we can work out a solution that does apply? Thanks. Smylers -- http://twitter.com/Smylers2
