RE: [Expectperl-discuss] Where is send.al in Expect.pm module?

[BLACKSTONE, J. D. <jda...@ci...>]

> -----Original Message-----
> From: Slater Robert-WLRS12 [mailto:WL...@mo...] 
> Sent: Wednesday, February 19, 2003 7:56 AM
> To: 'exp...@li...'
> Subject: [Expectperl-discuss] Where is send.al in Expect.pm module?
> 
> 
> Hello,
> 
> I work in a CDMA test group for Motorola and we developed an 
> automation tool written in Perl5. We have used the Expect.pm 
> module to establish 'rlogin' session to various UNIX 
> machines. Everything is working fine in our facility.
> 
> We need to setup the same tool in a new lab in Bangalore, 
> India. They purchased an Ultra5 UNIX machine to be there 
> 'tools' server. We FTP'ed the Perl5 software distribution to 
> this new machine including the Expect.pm module. We are now 
> seeing the following error:
> 
> Can't locate auto/Expect/send.al in @INC (@INC contains: . .. 
> /usr/sbin /usr/test/atd/tools/Auto/Auto_Modules
> /usr/test/atd/tools/Auto/Auto_Modules/LapMessages
> /usr/perl5/5.00503/sun4-solaris /usr/Perl5/5.00503 
> /usr/perl5/site_perl/5.005/sun4-solaris /usr/perl5/site_perl/5.005 .
> /usr/test/atd/tools/Auto/R16_1/TEST_CASES) at 
> /usr/test/atd/tools/Auto/Auto_Modules/RCval.pm line 318
> 
> Can you please tell me were the send.al method is located for 
> the Expect.pm. We just need to know what the directory 
> structure is relative to the Expect.pm module.
> 
> Thanks for your help.
> 
> Regards,
> 
> Bob Slater

Bob,

  It sounds like you just tried to copy the whole perl distribution from one
system to another.  My experience says that never works out. :)

  I've never really understood where the .al files are.  I think that's an
autoloaded module file, with a split-out method (in this case, the send
method) from the larger module.  The autoloader looks it up somehow, in
@INC.

  Your @INC contains some very unusual things, like /usr/sbin, which
ordinarily does not contain Perl modules (or the autoloaded files and
architecture specific shared libraries that often go with them).  There's
some kind of a configuration issue here that apparently applies to one
machine but not the other.

  I highly recommend that your people become familiar with compiling perl
from scratch on each machine, according to my instructions at
http://use.perl.org/~jdavidb/journal/6477 .  These kinds of configuration
issues can be avoided when you build perl specifically for the machine.
Alternatively, after following these instructions, you can turn the whole
directory into a package for installation on machines of the same class.  By
"class," I don't just mean, "these are both Sun machines," but, "these are
both Sun machines configured as a webserver for application Xyzzy with
database option."

  This really becomes a configuration management issue.  Trying to debug to
confusions of modules and their locations and whether or not they are
installed and possible lost pieces and how do we get Perl on machine2 when
the app has only run on machine1 requires a formal policy based on
experience.

  Just my 2cents; hope it helps.

jdb