I have tcl 8.6 for Windows installed; from the documentation it would appear Expect is part of the package, but the Windows installer didn’t show it in its components. Also even though the locally installed documentation indicates Expect is installed I don’t see it anywhere in the installation dir.
Also if I create a simple tcl script with “package require Expect” at the top, I get error:
can’t find package Expect
can’t find package Expect
while executing
“package require Expect”
Is there any way to install it for Windows?
Thanks!
Ok so the problem is two fold. For one thing “Expect” package is not supported on 64-bit edition.
For another thing “teacup” is no longer available in the 8.6.+.
I got it going by downgrading to the 8.5.13 (though 8.5.18 should also be fine AFAIK).
Now, there are several caveats here. One of them is that being a 16-bit package trying to “spawn” a 64-bit Windows app would fail (“not supported”).
Regarding the documentation:
The documents are one-size fits all. They reflect what exists, not what’s installed or compatible with the particular platform you happen to be on. Expect will be on Linux and many other operating systems, so you get the documentation for the Linux version of Expect.
Expect is indeed not supported in a 64-bit Windows binary. The 32-bit version of Expect for Windows only worked because of off-label use of a debugging library. The 64-bit equivalent library can’t be used that way.
The Windows port of Expect is also known to have issues with changes made to cmd.exe with Windows 8, 8.1, and Windows 10. The last patch for Expect fixed a problem on Windows 7, so that’s the last version of Windows which is compatible with the Windows port.
OK thanks Support!
The version I get is as follows:
% package require Expect
5.43.2
Do you know if that patch is included? And yeah, this is on Win 10.
One of the major differences I see with the Linux version is that the output of exp_spawn is not “tee’d” to the calling terminal; it seems to only go in the internal buffer so I can’t quite see what’s going on.
I wonder if that is related to the changes in the cmd.exe from 8.8.1 you alluded to.
Yes, you probably have the Windows 7 patch. 8.5.13 is only seven years old, and that patch was released 11 years ago (or or less).
Also, yes, what you’re seeing fits with the known problems on Windows 8+. Spawn itself was blocked by 8.1, and the tee was broken in a different update.
Have you tried writing commands in PowerShell? PowerShell was MicroSoft’s answer for scripting remote server management, and my impression is that over the years it eventually got good enough.
Ok, thank you for the details!
yeah, but this is a legacy QA suite and we didn’t want to spend resources on using PS scripting or any other for that matter.
In the end I got much of the stuff working with Cygwin and its Expect package, which works well since this was a “Unix” port to begin with so Expect scripts are launched by Bash scripts - this saves me the hassle of having to run under WSL).
Some changes were necessary due to an “echo” issue with “send” but at least Spawn isn’t blocked on Win 10 with Cygwin, and its output is parsed by tcl/Expect.
So this can be marked as “solved”.
I am quite intimately aware of the debug hooks that E4W was using, as I was the one that wrote them. At the time (2004 or so), it was the only way to gain hooks into the spawned process for grabbing console writes.
If you ever consider a ground-up rewrite of the underlying mechanism, look into a method called Detours
See above. There has never been a 64-bit port of Expect for Windows. The original code only functions on 32-bit Windows up to Windows 7, and not beyond that.
My usual recommendation is to either switch your PC to running Linux so that you can continue to use the reference version of Expect, or switch your application to Powershell so that you can continue to use Windows (depending on whether being on Expect or being on Windows is the most important).