Hi,
It's been a long time since I used tcl or expect and i'm trying to hash something together to automate a series of analysis programs that require user interactivity.
A) to make life easier and
B) so i know the same parameters are always run
However, the individual jobs can take a while and I'd like to background them so I can start the next one.
I'd normally do this with ctrl-z and then bg unix commands but I can't figure out how to send those in expect and i've spent most of the day trawling the web trying to find out (having no immediate access to the o'reilly book).
Graham (or anyone else) please can you help?
Sam

Hmm ... I've not got the O'Reilly book to hand either ... I'm in a hotel in Liverpool and its on site across the city ... I'll see if I can grab it and have a thumb through and get back in 24 hours or so.

I put in that line, so it looks exactly like this:

#!/usr/local/bin/expect
puts "Enter 'hi', then ENTER"
expect "hi\n"
array names expect_out;
puts "buf: $expect_out(buffer)"

What I get is:

"expect_out" isn't an array
   while executing
"array names expect_out"
   (file "/home/scharmer/expect/trm22" line 4)

The problem here seems to be that I can't trference expect_out(...).

When I was chopping down my code, I was trying to fine the circumstances where I could reference expect_out(...) and when I couldn't.  It didn't seem to be consistant.

Andy

I've checked some on line docs I've got .... and I'm wondering if it's because you've neither done a spawn nor a send .... I know that expect can be used for keyboard input but it's not something I've played around with much .... just a thought

ok, glad i checked the post above because Andy's post really confused me
i found something indicating
send \032
and
interact
in combination should work but not the specific syntax i need. There's something in the manpage but it's long-winded and not easy to understand.

I'll fix the mixed up threads (that's what's happened) at the weekend.  I think you got confused by an answer to one question being posted in the wrong thread.

Having had a further think / look at the backgrounding issue.

a) If you've started a process within a spawned shell, you can send it a control-z, wait for a prompt, and send it a bg.

b) If you're wanting to spawn more processes directly in the current expect process, you must save the spawn_id variable as it would otherwise be overwritten by the next process you start. You can then expect from any one of a number of processes at once by giving the expect command a list (using the -i option) of processes to wait on.   It will return when it gets a suitable string from and process.

We have a sample script that pings lots of machines in parallel and updates - see http://www.wellho.net/resources/ex.php4?item=t212/pingle

Hi Graham,
I'm spawning a shell yes, could you tell me the precise send syntax please because everything I tried failed. At the moment I'm just waiting for the job to finish before starting to run the next one (not ideal)
when i run this analysis on the command line i background one job and then start the next in the same xterm so i don't need the script to do anything fancy.
S

If you're going to use my second recipe, there's a complete source code example at the link given.   Using the first recipe, you should be able to

send \032
expect {\$ }
send bg\n
expect {\$ }

You'll need to change the expect string to match the end of the shell prompt that your remote system generates.

hmm, okay I'll try that, it's very close to what i had but i could easily have had a typo in there. thanks a lot Graham.

that worked, i've no idea what i was doing wrong. Thanks Graham!

actually, it didn't work. it backgrounded the processes but didn't seem to continue running them. do i need to spawn a new shell for each process?
it's probably getting to be time for me to post the code but i know it's terrible

#! /usr/bin/expect

puts "What is the name of your trajectory file?"
gets stdin trajfile

puts "What is the name of your tpr file?"
gets stdin tprfile



spawn tcsh

#set up
send "gro314\r"
expect "]$ "
set timeout 900

#start analysis
send "g_rms -f $trajfile -s $tprfile -o 5_analysis/rmsd_std.xvg \r"
expect "Select a group: "
send "3\r"
expect "compare ? "
send "1\r"
expect "Select a group: "
send "3\r"
expect -exact "3\r"
send \032
#set timeout 900
expect "]$ "
send "bg\r"
expect "]$ "
#
#now do the domains analysis starting with domains.xvg
send "g_rms -f $trajfile -s $tprfile -fit -n index_std.ndx -o 5_analysis/domains_std.xvg \r"
expect "Select a group: "
send "20\r"
expect "compare ? "
send "1\r"
expect "Select a group: "
send "24\r"
expect -exact "24\r"
#set timeout 900
send \032
expect "]$ "
send "bg\r"
expect "]$ "


and so on....

on 12/13/04 at 12:51:21, skaye wrote:

actually, it didn't work. it backgrounded the processes but didn't seem to continue running them. do i need to spawn a new shell for each process? it's probably getting to be time for me to post the code but i know it's terrible

No - if you've spawned a shell, then that shell should be able to continue to run the backgrounded processes.  But if the background processes require input from the keyboard, then it would give you problems.  

As regards your code - err, yes, it's getting a little long-winded - as a general rule, if you find yourself repeating something there's probably an easier way.  For a long send-expect sequence, you could try making up a list of lists to describe the exchange, then iterating through the list with a foreach.  If that works, put it into a proc that you can re-use with different calling lists for each of your "constant" exchanges.

I'm suspending it after the user input has been entered though. At the moment only the last submitted job is running, the others seem to vanish into the ether.

---