> As I expact, I just fixed the scope errors but the problem remains.
> This is it:
>
> sub telnet_access
> {
> my $username = $main::username;
> my $passwd = $main::passwd;
Generally we want our subroutines to be passed arguments and return
values. The above has avoided the scoping symptom but not really fixed
the encapsulation problem. You should pass the username and password to
the sub rather than calling from the sub into the global scope.
> my $command_1 = "cd /home/chris/servlist/";
> my @ra;
> my $rs;
> my $t;
>
Its considered better style to declare your variables at first usage
rather than as a list at the top. This helps to get proper scoping and
to avoid spelling errors, etc.
> $t = new Net::Telnet (Timeout => 15,Prompt =>
'/\[datagate\]\/KOMM\/datagate
> > /') or die "cannot call telnet!\n";
>
> $t->open ("komm") or die "cannot establish a connection!\n";
> $rs = $t->login ($username, $passwd) or die "login failed\n";
>
>
> @ra = $t->print ( $command_1 ) or die "cannot change dir!\n";
> $rs = $t->print ( "./komm-test.pl" ) or die "cannot start script!\n";
The C<print> method is not used for running commands but is instead used
for sending input to the process on the other side. You should be using
the C<cmd> method to issue a command. Check back to the Net::Telnet
docs, specifically for the two methods. If 'komm-test.pl' is expecting
input from STDIN for instance you would use C<print> otherwise you
aren't likely to need it.
perldoc Net::Telnet for the documentation.
> print "$rs\n";
>
> $t->close ();
> }
>
> It runs without any errors but also without purpose, because it
doesn't start
> the script on the remote host. :-\
>
> Gruss Christian
>
>
http://danconia.org
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
