From: Larry W. Virden on
On Feb 3, 5:09 pm, wexfordpress <j...(a)wexfordpress.com> wrote:

>
> It could be a version mismatch. I run tcl and tk at the latest stable
> level, 8.5.8.
> Expect is at 5.44.1.11. I tried to download and compile the latest
> version of expect
>  but it errors off on the compile. It may be that expect and expectk
> have been left
> by the side of the road in the development process.

Most maintenance of Expect is now performed by ActiveState employees.

I build the CVS head expect and tcl on sparc solaris 8 using Sun's C
compilers. They build and install. Howevfer, when I attempt to use
expectk with your script I get the error:
Application initialization failed: version conflict for package "Tcl":
have 8.6b1.1, need exactly 8.6

I'm going to submit a bug report at http://expect.sf.net/
From: ljb on
john(a)wexfordpress.com wrote:
> Here is the code:
> ---------------------------------------
> button .b -text "Hello world" -command exit
> pack .b
> ------------------------------------
>
> If called as "wish hello.tcl"
> it executes as expected.
>
> if called as "expect hello.tcl"
> it errors off on the button command. Fair enough.
>
> if called as "expectk hello.tcl"
> it displays the button but the button is inactive.
>
> My version of expectk is
> 5.44.1.11
> and the platform is Slackware Linux 13 with xfce.

Yes, there is something wrong with the expectk wrapper, at least in
Slackware 13.0. What seems to be happening is that none of the key bindings
are created, because the initialization scripts aren't being run. So the
keys don't work on the widgets.

Expectk seems to have its own version of the Tk initialization procedure,
and it appears to not work right. That was as far as I got, but it
didn't look to me like the problem is Slackware specific.

If you need expect and Tk together, you might have more success running
expect and then using {package require Tk}.
From: Larry W. Virden on
On Feb 4, 7:04 am, "Larry W. Virden" <lvir...(a)gmail.com> wrote:

>
> I'm going to submit a bug report athttp://expect.sf.net/

Turns out I already had submitted a bug report about this issue some
time ago.