surely, you're assuming that the path to ls is with the relevant user. Try this one, though I haven't actually tested it, to be honest.... :)
use Net::SSH::W32Perl;
my $ssh = Net::SSH::W32Perl->new($host,debug=>1);
$ssh->login($user, $pass);
my($stdout, $stderr, $exit) = $ssh->cmd("/bin/bash /bin/ls -lrt");
| [reply] [d/l] |
Maybe the shell on the remote system is just upset on e.g. your terminal settings or lack of those. Doing such as tset -Q or eval `resize` or the like, or asking Term? and getting no answer. I'd check that with an account that just has /bin/sh as login shell and all startup files disabled.
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] [d/l] [select] |
i couldn't understand can u explain in detail
| [reply] |
First, can you login into the remote machine using an ssh command line client, such as http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html ?
If you login to a remote machine, your login shell is spawned - one of sh, ksh, bash, csh, tcsh. You can lookup ypur shell in the file /etc/passwd on the remote machine.
Please consult the login manual page of the remote system for details on the login process, and the manual page for your login shell for it's startup sequence.
On startup, the login shell processes various rc files to set $PATH, the value of $TERM, the height and width of the terminal, system wide aliases for commands and so on.
If such code as setting up the terminal is carried out regardless whether there was a controlling terminal (pty) set up for this session, various commands to set up the environment could hang. E.g. a shell could ask for your terminal type at the command prompt, if it is unable to determine it from the environment.
Depending on the shell and remote system, the shell startup files are one ore more of /etc/profile, /etc/bashrc, /etc/csh.csh, $HOME/.profile, $HOME/.bashrc, $HOME/.cshrc etc. Check if those files contain terminal initialization code, and if possible, disable it.
Since Net::SSH::W32Perl doesn't support the shell method, there should be no pty allocated, but you can explicitly disable it.
Try the following:
use Net::SSH::W32Perl;
my $ssh = Net::SSH::W32Perl->new($host,
debug => 1,
use_pty => 0,
);
$ssh->login($user, $pass);
my($stdout, $stderr, $exit) = $ssh->cmd("ls");
--shmem
_($_=" "x(1<<5)."?\n".q·/)Oo. G°\ /
/\_¯/(q /
---------------------------- \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}
| [reply] [d/l] |
One other note: I'm assuming that you're connecting to a UNIX machine from a Windows Machine, with this one....Otherwise, the example I've given will NOT work! :) | [reply] |
| [reply] |
Hi. You'd need to use them separately, as advertised on CPAN. However, the overhead, programming wise, is completely minimal.
You probably, though, want to avoid having a username/password wired directly into a perl script, I would have thought......!
| [reply] |