in reply to Re^2: Net::SSH::Expect output
in thread Net::SSH::Expect output

This doesn't look like expect code. It looks like regular old read-the-file-regex-output code. So, you may be missing the cool expect features.

I have a guess: ssh and Expect can't really know what's prompt and what's command output. It's all a stream on stdout. You probably have to clear a buffer or something like that after you log in but before you run the command. It's significant that it's the 1st line on server2, because that's what you'd expect to see if you logged in and typed a command.

Does it always happen on server2? If so, it might be a shell setting specific to that account and that server.

Finally, you could just regex out the prompt from the input. You don't need to worry about speed so an extra regex on each line won't hurt anyone.

Really Finally, you could scrap SSH::Expect and use ssh with public keys instead of passwords. That might set up the environment better and not show you the prompt. Since you're not really using the expect features, that might be an easier way to go.

Replies are listed 'Best First'.
Re^4: Net::SSH::Expect output
by sierpinski (Chaplain) on Jul 23, 2009 at 19:09 UTC
    Currently it is just regular old read/regex code, but I do have plans to add the expect features once I get this part working.... and I do have ssh keys set up. I'm not passing it a password when I create the object (mostly because this is running under an account where not everyone should know the password).

    It always happens on server2, but server2 is no different than server1. They have the same OS version, and the ID is the same for both, (automounted home directory) so it's using the same profile and env variables and all that.

    It's not too much trouble to regex out the prompt, I can do that easily enough, I was just hoping there was some cool Expect feature that would do that for me, or maybe I was doing something wrong.

    One other thing I'm running into, however, is that when I come across a server that my key doesn't work on (ie one that does not use autofs for home directories) I get a password prompt. I'd like to be able to just detect these, add it to my no-connect list with a comment, so I can get a list of servers that need a manual key set up later, but instead it's trying to execute the commands, (in essence pressing enter 3 times) then getting the permission denied keyboard/interactive message, then the SSH connection dies, so I receive the SSHProcessError message.

    It's obvious to me I need to use more of the expect features, as that would (probably) easily fix my most recent problem, but it does lead me to another question:

    If I create an ssh connection, then issue a waitfor (or expect) statement, what keeps the prompt from displaying too fast for the waitfor, so then I'm waiting for nothing until the timeout. For example:

    1. ssh serverX
    2. (serverX asks for a password - Password:)
    3. waitfor "Ppassword:"

    What keeps that from happening, or does it just queue up in STDIN?

    Thanks!
[reply]

      Hey, I can answer this! Cool!

      Something is different about server2. Really, it is. It may not be worth looking for, but there is something.

      There is a cool expect feature to cut out the prompt, actually it's more of the entire purpose of expect than a feature.

      Re the no-key problem, again this is what expect is great for. It can compare input to a list of patterns, so if it gets a "password: " instead of a command line, it can do whatever you want. You're also not limited to whole lines or lines ending with a newline, so it won't have trouble because the cursor is sitting there on the same line as the "password: " prompt.

      Re the waitfor, yup you got it. The whole thing is in the stdin. As long as a previous expect statement hasn't cleared out the buffer, you're fine.

      You may want to step back and play with expect by itself and then apply it to SSH, rather than making SSH work before moving on to expect. Expect takes a little work to wrap one's head around, so it might be worth while to do that in a simplified environment.

[reply]

In Section Seekers of Perl Wisdom