Re: Expect scripting error

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

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.