Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Expect & Seyon (xterm)

18 views
Skip to first unread message

Kenny McCormack

unread,
Feb 24, 2007, 6:25:42 PM2/24/07
to
You may or may not have heard of "Seyon" - it is terminal (serial)
program for X. Aside: Seyon is kinda old and crotchety, but it has the
virtue that it works, and one thing that's always been a little thin
on the ground is serial comm programs under Linux. Note: I'm not
interested in alternatives to Seyon; the last sentence is only mentioned
as an aside.

Anyway, Seyon has two "interesting" attributes:
1) It uses an "xterm" as the UI. I.e., the program doesn't
itself actually display a terminal screen; it leverages
xterm to do that.
2) It has a whacky, almost impenetrable scripting language.

Now, having used Expect to control an Xterm, as is shown in the book
(and in the code below), I feel like I could use #1 as a way of
ameliorating #2. I.e., if I could insert Expect between Seyon and its
xterm, then I could use Expect/Tcl to script my communications sessions
and not have to learn "yet another scripting language". Seyon provides
a hook to specify what program to use as its "terminal emulation
program", defaulting to "xterm". What it does is redirects stdin/stdout
of the terminal program to the comm port. So, if I could setup an
Expect script along those lines, I should be in.

I played around a bit with the code below (taken almost directly out of
the book), but was unable to get it to work. Any ideas?

--- Cut Here ---
#!/usr/bin/expect --
set timeout -1
if [catch {puts "DISPLAY = $env(DISPLAY)"}] {
send_user "DISPLAY: "
expect_user -re "(\[^\r]*)\n"
set env(DISPLAY) $expect_out(1,string)
}
spawn -pty -noecho
puts "My slave's name is: $spawn_out(slave,name)"
set xterm_spawn_id $spawn_id
stty raw -echo < $spawn_out(slave,name)
regexp ".*(.)(.)" $spawn_out(slave,name) dummy c1 c2
if {[string compare $c1 "/"] == 0} { set c1 "0" }
set xterm_pid [exec xterm -T "My Xterm: $env(USER)" -S$c1$c2$spawn_out(slave,fd) &]
close -slave
send_user "His WindowID is: "
expect eof {exit} "\n"

if {$argc == 0} { spawn $env(SHELL) } else { eval spawn $argv }

interact {
-input "$user_spawn_id $xterm_spawn_id" -output $spawn_id null {}
-input $spawn_id -output "$user_spawn_id $xterm_spawn_id"
}
exec kill $xterm_pid
puts "\nBye - bye!\n"

Bezoar

unread,
Mar 2, 2007, 3:54:19 PM3/2/07
to gaz...@xmission.xmission.com
On Feb 24, 5:25 pm, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:

Have you tried to use the "xterm -e <command>" as the xterm
command.Put your script where <command> is . Seyon will bring up your
xterm with your script running and the xterm will now have its stdin
and stdout correctly redirected by seyon.

Carl

Kenny McCormack

unread,
Mar 10, 2007, 9:33:45 AM3/10/07
to
In article <1172868859.5...@v33g2000cwv.googlegroups.com>,
Bezoar <cwj...@gmail.com> wrote:
...

>Have you tried to use the "xterm -e <command>" as the xterm
>command.Put your script where <command> is . Seyon will bring up your
>xterm with your script running and the xterm will now have its stdin
>and stdout correctly redirected by seyon.

But wouldn't that result in two xterms running? I.e., the execution
path would be:

Seyon -> "xterm -e <command>" -> Expect -> "xterm spawned by (*) Expect"

Seems wrong to me.

(*) And controlled by

0 new messages