Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine

Cannot call my installed module

by ShermW0829 (Sexton)
on Feb 23, 2013 at 22:26 UTC ( #1020350=perlquestion: print w/replies, xml ) Need Help??
ShermW0829 has asked for the wisdom of the Perl Monks concerning the following question:

I am trying to get a perl script to run my own installed module. I am getting the below message.

 Undefined subroutine &testdir::testsub called at call_module line 11.

I installed the module using the following code

 module-starter --module=testdir::moduletest --author="Sherman Willden" --license=perl --verbose

The install directory is /home/sherman/module_test/share/perl/5.14.2/testdir/ I am including the .pm code and the .pl code. The perl file calling the .pm file works when I use require.

#! /usr/bin/perl # # package testdir::moduletest; use Exporter(); # Why is Exporter white while other use # statements are colored $VERSION = '0.00.01'; @ISA = qw(Exporter); @EXPORT = qw(testsub); @EXPORT_OK = qw($string); sub testsub { =head1 SUBROUTINE The testsub subroutine is just a test function that determines that four variables are seen with the testsub function and returns a string created within the testsub function. =cut print "In my testsub function\n"; print "\$_[0]: \"$_[0]\"\n"; print "\$_[1]: \"$_[1]\"\n"; print "\$_[2]: \"$_[2]\"\n"; print "\$_[3]: \"$_[3]\"\n"; my $string = "My string\n"; return("$string"); } 1; __END__ =head1 NAME testdir::moduletest =head1 SYNOPSIS Provides one called function, testsub =head1 DESCRIPTION This is a test module with provides valued passed in, print statements that show the variables passed in, a string created and returned from with testsub =head1 AUTHOR Sherman L. Willden =head1 COPYRIGHT Copyright 2013, Sherman L. Willden. All Rights Reserved This program is free software. You may copy or redistribute it under the same terms as Perl itself. =cut

Here is the callin perl file's code:

#! /usr/bin/perl -w # use V5.14.2; use lib '/home/sherman/module_test/share/perl/5.14.2'; # Since this didn't work I am checking for my path within # the perl path print qq(@INC); # require '/home/sherman/build_dir/testdir/'; my $moduletest = testdir::testsub(0,2,0,2); chomp($moduletest); print "moduletest: \"$moduletest\"\n"; 1;

Replies are listed 'Best First'.
Re: Cannot call my installed module
by 2teez (Vicar) on Feb 23, 2013 at 23:05 UTC

    I am trying to get a perl script to run my own installed module. I am getting the below message. Undefined subroutine &testdir::testsub called at call_module line 11.

    Obviously, perl is telling you that the subroutine &testdir::testsub, used in line number 11 in your script is not available! Why? it was never "loaded".
    Note is either you un-comment your this line:
    # require '/home/sherman/build_dir/testdir/'; or add use testdir::moduletest; indicating where the subroutine you used in line number 11 is located.
    Please also check perlmod
    Hope this helps.

    ## Update:

    • I think this use V5.14.2; in your script should be use v5.14.2;
    • Adding this use testdir::moduletest;
      You can just easily call your subrotrine like thus:
      my $moduletest = testsub(0,2,0,2);
      And you are good to go :)...
    • it's also good practice to add use strict; to your scripts. Just saying...

    If you tell me, I'll forget.
    If you show me, I'll remember.
    if you involve me, I'll understand.
    --- Author unknown to me
Re: Cannot call my installed module
by fishmonger (Chaplain) on Feb 23, 2013 at 22:50 UTC

    Did you try loading the module with a 'use' statement?

    Add this:

    use testdir::moduletest;
      I forgot to mention that you need to add that after the 'lib' statement.
Re: Cannot call my installed module
by tobyink (Abbot) on Feb 23, 2013 at 23:02 UTC
    my $moduletest = testdir::moduletest::testsub(0,2,0,2); # ^^^^^^^^^^^^
    package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
Re: Cannot call my installed module
by 7stud (Deacon) on Feb 24, 2013 at 04:18 UTC
    # Why is Exporter white while other use
    # statements are colored

    I don't know, but I can confirm that the same thing happens in macvim with the vividchalk color scheme:

    use strict; #strict is same color as use, which is orange use warnings; #same as previous use 5.012; #5.012 is blue use vars; #vars is orange use Benchmark qw(:all); #Benchmark is white use List::BinarySearch; #A module I installed is white

    Experimenting with different modules, it appears that lower case builtin modules appear in orange, while any upper case module name is white.

    Note that @INC contains the list of directories that perl will search for modules--that you use. There are lots of modules in those directories, but perl will only load them into your program, if you use them. If you look at the use docs, the statement 'use Module' is equivalent to:

    BEGIN { require Module; Module->import( LIST ); }

    What does that mean? Well require() does this:

    ...require demands that a library file be included if it hasn't already been included. The file is included via the do-FILE mechanism, which is essentially just a variety of eval...

    Which means that perl searches the directories in @INC for the specified Module, and if found perl then evals the text file converting it into code. After the require, perl calls a subroutine named import() that is defined in Module. Typically, the import() method creates aliases in the caller (i.e your perl program) for the subroutines defined in the Module--which allows your program to call the subroutines. The following lines in your program take care of the aliasing for you:

    @ISA = qw(Exporter); @EXPORT = qw(testsub); @EXPORT_OK = qw($string);

    If you are worried about the subroutine names in the Module clashing with names in your perl program, you can write:

    use Module ();

    And thereafter, you can refer to the subroutines by their fully qualified names, e.g. Dir::Module::subroutine_name

    But perl cannot see the subroutines defined in a text file just because the text file resides in a directory in @INC. You have to convert the text file to code with use/require. Your 'use lib' just adds a directory to @INC.

      Thanks all. This is good. Sherman

        Doing the following as suggested worked

         use lib '/home/sherman/module_test/share/perl/5.14.2';

         use testdir::moduletest;

        thank you all. I was banging my head and I kept re-reading and it didn't make sense at the time.

Re: Cannot call my installed module
by Anonymous Monk on Feb 24, 2013 at 00:57 UTC
Re: Cannot call my installed module
by sundialsvc4 (Abbot) on Feb 25, 2013 at 13:35 UTC

    Here is a very short checklist that I use to initially diagnose such problems:

    1. Make sure that the module that you think you’re referring to really is installed, and where you think it is.   (Don’t assume.)
    2. Issue the command, “perl -V” (with an upper-case “V”) and look at the library search-list to be sure that the specified directory really is on it.   Remember that on a Unix system if you edit .bash_profile to modify the PERL5LIB environment variable, you must source .bash_profile to cause it to take effect, as the env command will subsequently confirm.
    3. Ensure that the package-name you are referring to has been brought into the program via use or require.   (See also: UNIVERSAL::require.)
    4. In this particular case, where the package-name is obtained by means of a variable or string, use print STDERR this_expression to, once again, show (don’t assume ...) what this string actually contains at runtime.
    5. Bear in mind the differences between where CPAN installs a package, as determined by its configuration, and where Perl at runtime looks for a package (see #2 above).   The two are not the same and must agree.   Otherwise, here is one of several ways that you will see that you can install a package but can’t call it.

    HTH ...

Re: Cannot call my installed module
by opitzs (Sexton) on Feb 25, 2013 at 09:57 UTC
    use Exporter(); # Why is Exporter white while other use # statements are colored
    In vim (and I guess other Editors as well) Exporter is not a known word/module, as it is loaded externally. This happens also e.g. with
    use Data::Dumper;
    You can edit the syntax file (perl.vim in the syntax directory), if you want it to be recognized as a reserved word.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1020350]
Approved by Corion
Front-paged by 2teez
and all is calm...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (14)
As of 2018-06-25 13:44 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (126 votes). Check out past polls.