Re: Expect scripting error -- MIDRANGE-L

Hi John,

Not sure that I follow what was actually exchanged with the support person, or what you learned from it... But from the debug output you posted, Expect was seeing this:

Connecting to XXXXX.com....

and then was not receiving any other data after that. The usual cause of that is that port 22 is blocked by a firewall, and you can't reach port 22. (Possibly for a particular host, or possibly for all of them.)

Have you tried running it interactively? I don't mean from a completely separate Windows computer, I mean have you tried it interactively from your IBM i? The same IBM i where the Expect script is running?

And DON'T insert code that does expect "" send "" -- You don't want to wait for nothing and send nothing! That makes no sense... As I said before, the message that says expect: does "" match "password:" is NOT a problem, it's normal expected behavior, and is what you want to see. Don't change your script to compensate for it, you'll almost certainly make things worse.

John McKee wrote:

I was on the phone with a support person for nearly two hours today. I learned
a few things, none of which have solved the problem as yet. Maybe some of this
will make sense to somebody else, as it did not to the tech person, or to me.

1) The target system is running Windows, so logging appears to be minimal, from
what I was told.

2) When I connect using Cygwin on my pc, I get: Connecting to ftp.xxx.com...,
but when I try on System i, I get: Connecting to xxx.com.

3) The next thin in the log on System i is Expect "". Inserting an actual pair
of lines to: expect "" and send "", produces in the log that the '' was
expected, nd sent, followed by another expected "". I played that games for a
while. Had five pairs of expect "" send "", and it prompted for a sixth.

4) Never got to the point where the password prompt was expected and password
was properly sent.

Does this make any sense?

John McKee

Hi Scott,
Thanks for mentioning the ln. Too many thing I could potentially do that get
people ticked off around here. Me guessing at an appropriate LN would be one
of those, if something else quit working around midnight.....

Here is some of stderr:

executing commands from command file /tmp/escandatasystems.scr
parent: waiting for sync byte
parent: telling child to go ahead
parent: now unsynchronized from child
spawn: returns {540}

expect: does "" (spawn_id exp3) match glob pattern "password:"? no

expect: does "Connecting to " (spawn_id exp3) match glob pattern "passwo

expect: does "Connecting to xxxxx.com" (spawn_id exp3) match

expect: does "Connecting to xxxxx.com...\r\n" (spawn_id exp3)
expect: timed out

I just checked again with Cygwin, end of the password prompt is password: - so
is the script mistimed where it reports 'no'? I can sign on with Cygwin, so
the account has not been locked. But, I don't see anything other than:

Connecting to xxxxx.com
xxx's password:

Am I invoking it correctly with:

===> call qp2shell parm('/usr/local/bin/expect' '-df' '/tmp/xxxxx.scr')

Looks like what you have in your article to me.

John McKee

Quoting Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>:

Hi John,

The stty errors are because Expect wants the stty program to be in the
/usr/local/bin directory, whereas in PASE it's located in
/qopensys/usr/bin. You can solve the problem by doing (from PASE):

ln -s /QOpenSys/QIBM/ProdData/OS400/PASE/bin/stty /usr/local/bin/stty

That'll set up /usr/local/bin/stty as an alias, so Expect can use it.

The pattern not matching isn't really a problem. When you tell Expect
to show you diagnostics, it'll show you all of the lines that it
processes that do not match your string. It says that "" (a blank line)
doesn't match "password:" which is normal -- it shouldn't match. The
line following the blank line might have "password:" or maybe the one
after it. It's not a problem unless NOTHING matches...

Please fix the stty thing, and then maybe the log will make more sense...

John McKee wrote:

Following Scott' examples, I have been trying to get a script to
connect to a
remote site for sftp. It isn't working right, but, at least, it is
not locking
up the remote system either.

First, from working with scripting in the past, I assumed that the search
pattern does not have to be the entire string. In this case, the
remote site
sends back a rather long user name, followed by 's password:. I have tried
running this with the entire user name as well as just password:.

I get the same error each time. My first thought is that something else is
missing.

Anyway, this is what I receive in stderr:

spawn: returns {494}

expect: does "" (spawn_id exp3) match glob pattern "password:"? no

expect: does "sh: /usr/local/bin/stty: not found.\r\n" (spawn_id ex

expect: does "sh: /usr/local/bin/stty: not found.\r\nConnecting to

expect: does "sh: /usr/local/bin/stty: not found.\r\nConnecting to

expect: does "sh: /usr/local/bin/stty: not found.\r\nConnecting to
expect: timed out

My questions:
1) I have logged in manually, and I can confirm that the trainilg
part of the
password prompt is indeed password:. So what is the expect trying
to tell me
when it tates that the pattern does not match?

2) Notice a little further down the not found related to
/usr/local/bin/stty? I
have Cygwin on my desktop. Looking for stty, it is in /usr/bin. But, even
looking there on the i, I do not see it.

Any thoughts?

Thanks.

John McKee

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.