Training, Open Source computer languages
PerlPHPPythonMySQLApache / TomcatTclRubyJavaC and C++LinuxCSS 
Search for:
Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
For 2021 - online Python 3 training - see ((here)).

Our plans were to retire in summer 2020 and see the world, but Coronavirus has lead us into a lot of lockdown programming in Python 3 and PHP 7.
We can now offer tailored online training - small groups, real tutors - works really well for groups of 4 to 14 delegates. Anywhere in the world; course language English.

Please ask about private 'maintenance' training for Python 2, Tcl, Perl, PHP, Lua, etc.
Expect Segfaulting

Posted by vsriharsha (vsriharsha), 4 May 2005
Hello All,
Im new to Expect and have been going through some tutorials online (which by no means present the complete picture). I've tried for the book "Exploring Expect", but here (in India), the book-shop people say that it is a 'foreign edition' and hence is not available here. And to import it, will cost me a fortune. Anyway, here is my problem:

I have a program that runs fine from shell, but is seg-faulting when spawned from Expect. We have a custom port of gdb called rpine-elf32-gdb. Here is the script that causes the SIGSEGV (run with Expect 5.3
spawn /opt/rpine/bin/rpine-elf32-gdb -q test
expect "(gdb) $"
send "tar sim\n"

Here, I get a "Segmentation Fault" for expect "(gdb) $"
But if I manually run the same program, it works fine.

So, what is going wrong?


Posted by admin (Graham Ellis), 4 May 2005
Some things that can cause apparent different behaviour in manually and automated (via expect) scripts

a) Timing. It may be that Expect is too quick for the spawned process.  Lokk at delays and things like send_slow.

b) Sending strings with \n on the end when you should be using \r. Although \n (new line) is the Unix and Linux end of file, it's \r (return) that you press at the keyboard at the end of a command and so it's often \r that needs to go into the send string

c) No waiting for the complete prompt string before you respond. For example, should there be a space after the $ character in your prompt?   That can make all the difference.

It's never obvious what's the cause of things like this ... so you'll need to experiment. Do try setting log_user such that you can see how far your code gets, and exp_internal may help too.  Please follow up to let us know how you get on / what you find.

Posted by vsriharsha (vsriharsha), 4 May 2005
the following is the code that Im trying to run and a sample run on the machine:
#!/bin/expect -f
set timeout 5
log_user 1
exp_internal 1
spawn /opt/rpine/rpine-elf32-gdb -q a.out
sleep 2
expect -- "(gdb)"
send "tar sim\r"
expect -- "(gdb)"
send "load a.out\r"
expect -- "(gdb)"
send "b main\r"
expect -- "(gdb)"
send "run"
[root] ./escript.exp
spawn /opt/GNUPlus/rpine/bin/rpine-elf32-gdb -q T001_rpine
parent: waiting for sync byte
parent: telling child to go ahead
parent: now unsynchronized from child
spawn: returns {853}

expect: does "" (spawn_id exp4) match glob pattern "\u4003\u4003\u4003\u4003\u4003"? no
(gdb) Segmentation fault
So, what I understand is that the string that Im passing to 'expect' command is being mis-interpreted as some unicode characters (I guess \u4003 corresponds to some unicode character).

Another mystery is: This program works perfectly fine in another machine. Both the machines are running Redhat 8.0 and Version 5.38 of Expect. Even the TCL versions are the same. What more environment variables need to be checked (I checked $LANG variable and both are same).

I've tried different types like
expect "(gdb) $" etc etc... but to no avail.

Any idea about the misinterpretation of the string?


Posted by admin (Graham Ellis), 5 May 2005
You haven't got any strange non-printable characters in the script on the machine from which the code fails have you?   Try checking the script with vi in list mode (enter vi and then :set list) and see if it reveals anything, or check it with od -c

Posted by vsriharsha (vsriharsha), 5 May 2005
Hi Graham,
I've just checked as you mentioned. There are no strange characters in the file. Every line is suffixed by a $ symbol. Anyway, here is how it showed me when I used :set list in vi.
#!/usr/bin/expect -f$
set timeout 2$
log_user 1$
exp_internal 1$
spawn /opt/rpine/bin/rpine-elf32-gdb -q test$
expect {$
"(gdb)" {send_user "PASS"}$
timeout {send_user "FAIL"}$

This is how it showed me with od -c
[harsha:/work/TEST/test-suite]od -c test.exp
0000000   #   !   /   u   s   r   /   b   i   n   /   e   x   p   e   c
0000020   t       -   f  \n   s   e   t       t   i   m   e   o   u   t
0000040       2  \n   l   o   g   _   u   s   e   r       1  \n   e   x
0000060   p   _   i   n   t   e   r   n   a   l       1  \n   s   p   a
0000100   w   n       /   o   p   t   /   r   p   i   n   e   /   b   i
0000120   n   /   r   p   i   n   e   -   e   l   f   3   2   -   g   d
0000140   b       -   q       t   e   s   t  \n  \n   e   x   p   e   c
0000160   t       {      \n   "   (   g   d   b   )   "       {   s   e
0000200   n   d   _   u   s   e   r       "   P   A   S   S   "   }  \n
0000220   t   i   m   e   o   u   t       {   s   e   n   d   _   u   s
0000240   e   r       "   F   A   I   L   "   }  \n   }  \n   i   n   t
0000260   e   r   a   c   t  \n

As we can see, none shows any strange characters.
Right now Im running those tests on the working machine. But its getting on my enthusiasm to see why its failing on the other system.


Posted by vsriharsha (vsriharsha), 10 May 2005
Hello Graham and others,
 The issue has been resolved finally. No miracles or brainwaves. Just that, on the test machine I installed expect-5.38.0-88.i386.rpm. I erased and replaced it with the version I had on other machines: expect-5.38.0-74.i386.rpm and behold.... It works like magic.....

So, I guess its all related to some enhancements in the Expect version.

Anyway, thank you very much for your time.


Posted by admin (Graham Ellis), 10 May 2005
Thanks for that follow up ... there had to be something different  

This page is a thread posted to the opentalk forum at and archived here for reference. To jump to the archive index please follow this link.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2022: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: • WEB: • SKYPE: wellho