Tcl/Expect for Windows
Sid Pollock
Our team has been using TCL/Expect on UNIX to drive test cases to test an
application that runs on UNIX.
This very same application also runs on Windows so we are looking at
"porting" the TCL/Expect scripts over to Windows so that we can drive test
cases to test the application on Windows.
We figure that we will have to modify the test cases to work on Windows.
We also think that we will need to use "TCL/Expect for Windows".
We are not interested in creating GUIs with TCL/Tk or using TCL/Expect for
Windows as a GUI builder. We are simply interested in running DOS-based
tests on commands executed in a DOS Command Prompt window (on W2K or XP).
Do we really need to use TCL/Expect for Windows or can we control tests in a
DOS Command Prompt environment using TCL/Expect?
Also, the example tutorials on the ActiveState site all seem to be geared to
running a TCL script from Windows to control a UNIX environment. That seems
a bit off. I would like to see examples of TCL scripts running on Windows to
control a Windows environment.
This simple example of test.tcl works fine. It doesn't use exp_spawn but it
can. It also uses "set exp::winnt_debug 1" so that I can see the results of
the execution in a DOS Command Prompt window. I suppose this answers my
question about not needing "TCL/Expect for Windows" or am I dreaming in
colour:
execute:
C:\> C:\tcl\bin\wish test.tcl
-------------------------------
#!/bin/sh
# \
exec tclsh "$0" ${1+"$@"}
package require Expect
set exp::winnt_debug 1
set timeout 300
spawn C:\\WINNT\\SYSTEM32\\CMD.EXE
expect {
-re ">$" {
send "dir /b\r"
expect {
-re ".+" {
puts $expect_out(buffer)
}
timeout {
puts "ERROR: timed out"
}
}
}
}
expect {
-re ">$" {
send "pause\r"
expect {
-re ".+" {
puts $expect_out(buffer)
}
timeout {
puts "ERROR: timed out"
}
}
}
}
expect {
-re ">$" {
send "exit\r"
}
}
-------------------------------
David Gravereaux
>I suppose this answers my
>question about not needing "TCL/Expect for Windows" or am I dreaming in
>colour
No, you're not dreaming.. It really does work. About the "controlling
Unix apps" you mentioned.. Expect isn't doing that. Expect is
controlling the local telnet/ssh client that is connected to "another
computer" running whatever is on that side in the telnetd VM.
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]
David Gravereaux
>"Sid Pollock" <pol...@nortelnetworks.com> wrote:
>
>>I suppose this answers my
>>question about not needing "TCL/Expect for Windows" or am I dreaming in
>>colour
>
>No, you're not dreaming.. It really does work. About the "controlling
>Unix apps" you mentioned.. Expect isn't doing that. Expect is
>controlling the local telnet/ssh client that is connected to "another
>computer" running whatever is on that side in the telnetd VM.
The applications that are compatible for [exp_spawn] can only be Win32
apps that run in the console subsystem (CLI or TUI).
For example, try this from tclsh84:
% set p [open |telnet r+]
file811680
% fconfigure $p -blocking 0
% read $p
% eof $p
1
% close $p
child killed: SIGABRT
%
Why did telnet not want to run in a pipe? Ahh.. This is the difference..
[open |* r+] and [exec] run applications in a pipe. apps like telnet are
TUI (text user interface) and require a console to draw to. A pipe is a
text stream, not a terminal (console) and telnet requires one. Expect is
designed to not only run simple command-line-interface apps that only
write/read from the std channels, but apps that require a console too.
This is the difference.
Just to be fair, cmd.exe can run in a pipe, too.
% set p [open |[string map {\\ /} $env(COMSPEC)] r+]
file811680
% fconfigure $p -blocking 0 -buffering none
% read $p
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
D:\Tcl\bin>
% puts $p {dir /b}
% read $p
dir /b
appLaunch.tcl
base-tcl-win32-ix86.exe
base-tk-win32-ix86.exe
iconv.dll
libexslt.dll
libxml2.dll
libxslt.dll
Parameters
procheck.exe
tcl84.dll
tclapp.tcl
tclchecker.exe
tclchecker.tcl
tclcompiler.tcl
tcldebugger.tcl
tclinspector.tcl
tcllauncher.tcl
tclpe.tcl
tclpip84.dll
tclsh.exe
tclsh84.exe
tclsvc.tcl
tclsvc84.exe
tclsvckit.exe
tclvfse.tcl
tclxref.tcl
tk84.dll
tkcon.tcl
Untitled
wish.exe
wish84.exe
zlib.dll
D:\Tcl\bin>
%
Cameron Laird
David Gravereaux <davy...@pobox.com> wrote:
>"Sid Pollock" <pol...@nortelnetworks.com> wrote:
>
>>I suppose this answers my
>>question about not needing "TCL/Expect for Windows" or am I dreaming in
>>colour
>
>No, you're not dreaming.. It really does work. About the "controlling
>Unix apps" you mentioned.. Expect isn't doing that. Expect is
>controlling the local telnet/ssh client that is connected to "another
>computer" running whatever is on that side in the telnetd VM.
.
.
There are several questions afoot here.
Mr. Pollock, you did well to emphasize that your application is
"pure command-line", even though hosted on Windows. Yes, you
absolutely can use Expect-for-Windows in a straightforward way
to drive your application. With any luck, in fact, you even can
use an older Expect, available at no charge, rather than the one
from ActiveState. ActiveState deserves your business, and I
suspect you'd do well to purchase from them; if it's useful to
you, though, the fee-free version might suffice.
There might even be a way to run your tests with "pure Tcl", if I
understand your description correctly. Let me know if that
interests you.
I admit to confusion about whether we've addressed everything you
raised. If not, ask again.
Sid Pollock
I actually want to "avoid" using Expect-for-Windows and just use "Expect"
simply because we are not creating Window GUIs. We are simply executing
commands in the DOS Command Prompt window. So your response:
"Yes, you absolutely can use Expect-for-Windows in a straightforward way
to drive your application." is the opposite of what I was hoping.
Can I absolutely use "Expect" in a straightforward way to drive my
application?
Some of the other responses seem to indicate that ' Yes, I can absolutely
use
"Expect" and avoid "Expect-for-Windows" '.
Besides, I am not quite there yet. I am still trying to get my hands around
TCL
and these additional "Expect" commands for send, expect, etc.
Thanks again,
Sid
"Cameron Laird" <cla...@lairds.us> wrote in message
news:r5o622-...@lairds.us...
Cameron Laird
Sid Pollock <pol...@nortelnetworks.com> wrote:
>Thank you for your responses.
>
>I actually want to "avoid" using Expect-for-Windows and just use "Expect"
>simply because we are not creating Window GUIs. We are simply executing
>commands in the DOS Command Prompt window. So your response:
>
>"Yes, you absolutely can use Expect-for-Windows in a straightforward way
>to drive your application." is the opposite of what I was hoping.
>
>Can I absolutely use "Expect" in a straightforward way to drive my
>application?
>
>Some of the other responses seem to indicate that ' Yes, I can absolutely
>use
>"Expect" and avoid "Expect-for-Windows" '.
>
>Besides, I am not quite there yet. I am still trying to get my hands around
>TCL
>and these additional "Expect" commands for send, expect, etc.
.
.
I think you're going to end up happy. It might take
a couple more rounds of negotiating what words mean
to each of us.
You want to test an application running under Windows.
In fact, you want a computer program to run the test
automatically. On what machine do you want to run that
computer program? On the same Windows host where the
program you're testing lives, or on a different computer,
perhaps a Linux one like the one you're already using
for test automation? Or does it matter--would *any*
automation suffice for you, if you just knew how to set
it up and retrieve the results?
Bruce Hartweg
Sid Pollock wrote:
> Thank you for your responses.
>
> I actually want to "avoid" using Expect-for-Windows and just use "Expect"
> simply because we are not creating Window GUIs. We are simply executing
> commands in the DOS Command Prompt window. So your response:
>
> "Yes, you absolutely can use Expect-for-Windows in a straightforward way
> to drive your application." is the opposite of what I was hoping.
>
> Can I absolutely use "Expect" in a straightforward way to drive my
> application?
>
> Some of the other responses seem to indicate that ' Yes, I can absolutely
> use
> "Expect" and avoid "Expect-for-Windows" '.
>
> Besides, I am not quite there yet. I am still trying to get my hands around
> TCL
> and these additional "Expect" commands for send, expect, etc.
>
> Thanks again,
> Sid
>
I think part of the confusion might be what you think Expect-for-Windows is.
It is a modern port of Expect that runs on the windows OS. it is NOT anything
that will or can automatically drive a GUI display for testing.
there is an older port of expect that is free and somewhat runs on windows -
it is based on older code and does not handle many cases, but in some circumstances
it is enough.
there is teh cygwin expect, which works, but as far as I know, only works when
running other cygwin tools, not native windows/dos commands.
the Expect-for-Windows port from Activstate is a modern port, it does cost,
but it also comes with support, and will be the most robust solution.
Bruce
Victor Wagner
> We also think that we will need to use "TCL/Expect for Windows".
> We are not interested in creating GUIs with TCL/Tk or using TCL/Expect for
> Windows as a GUI builder. We are simply interested in running DOS-based
> tests on commands executed in a DOS Command Prompt window (on W2K or XP).
If your programs are really DOS based, why pay for Windows?
Run them in Linux DOSEMU and drive this DOSEMU with unix Expect.
If you confusing DOS-based apps and Windows Console apps, I doubt that
absence of expect is most serious problem ;-)
Although with some luck you can get around with Windows console apps
too. They might run under Wine.
BTW recent versions of Tcl/Tk stop working under Wine. Tcl 8.4.2 have
worked, and 8.4.5 doesn't. Because something was changed in serial port
code for Windows and it now uses API which is not implemented in Wine.
--
How do you power off this machine?
-- Linus, when upgrading linux.cs.helsinki.fi, and after using the machine for several months
Sid Pollock
It would appear that I am not getting an answer to my direct question
but a lot of suggestions on using Linux, older versions of
expect-for-windows
and the like.
Just to refocus.....
The application that I am trying to test MUST be tested in a Windows OS
environment. Any attempt to test it through alternative approaches such as
LINUX
just doesn't provide a true test of the applications capabalities UNDER
WINDOWS.
As for choosing to use ActiveState's supported version of Expect-For-Windows
vs. any older/freer version, my question is not which Expect-For-Windows I
should use
but SHOULD I NEED TO USE EXPECT-FOR-WINDOWS AT ALL.
OK. The application under test is ClearCase. ClearCase has a GUI
interface;ClearCase also has a Command Line Interface. We want to
specifically test the latter.
From what I have read so far about Expect-For-Windows, and granted that
hasn't been too much, I got the feeling that Expect-For-Windows uses
exp_send, exp_spawn, etc. because of
underlying differences with Expect for UNIX. Nevertheless, I have tried to
write simple routines using spawn and send without apparent problems. That
is why I question needing
to use Expect-For-Windows at all.
So, what is stopping me from simply using Expect when driving automated
tests on ClearCase in a DOS Command Window. What is so special about
Expect-For-Windows.
Also, I am not interested in using Tcl/Tk to "create" GUI apps on Windows. I
am interested in a Tcl solution to drive DOS Command Window application
testing.
Again, I really do appreciate the responses I have been getting but I
thought it was going a bit off on a tangent to solutions that were not
really focused on my question.
"Sid Pollock" <pol...@nortelnetworks.com> wrote in message
news:ciq60i$cjn$1...@zcars0v6.ca.nortel.com...
F. Michael Orr
Another option to consider. Put OpenSSH for Windows onto the Windows
machine. Then, from a Unix/Linux machine, you can ssh into the Windows
machine, which gives you a standard Windows command prompt, and run your
application via Expect on Unix/Linux machine. I have set up similar
configurations, and the only problem I have run into is the #!*$'ing
stupid "Program Files" nonsense with spaces in the directory names. And I
have been able to work around that by using the 8.3 type filenames.
Cameron Laird
.
.
We need to get in a room with visual aids and point until we understand
each other.
If you have something you call Expect that is giving you the results
you want for [spawn] and [send], I encourage you to use it. There is
nothing else you should need.
Several of us don't understand at all some of what you've written above.
That's not an insult in any direction; confusion just happens sometimes.
I *think* I know what "Expect-For-Windows" means to you, but I'm utterly
lost about what specific application (or applications?) you use that you
call "Expect".
There's one more sentence in what you write above that I think I can
address: "I am interested in a Tcl solution to drive DOS Command Window
application testing." That seems perfectly sensible to me. Tcl is a
great vehicle for automation of tests of DOS-console applications.
Jeff Hobbs
> but SHOULD I NEED TO USE EXPECT-FOR-WINDOWS AT ALL.
>
> OK. The application under test is ClearCase. ClearCase has a GUI
> interface;ClearCase also has a Command Line Interface. We want to
> specifically test the latter.
>
> From what I have read so far about Expect-For-Windows, and granted that
> hasn't been too much, I got the feeling that Expect-For-Windows uses
> exp_send, exp_spawn, etc. because of
> underlying differences with Expect for UNIX. Nevertheless, I have tried to
> write simple routines using spawn and send without apparent problems. That
> is why I question needing to use Expect-For-Windows at all.
Expect has long had the exp_* naming convention - even in the
traditional unix version. This was in order to help you
specifically differentiate 'close' from 'exp_close' and 'send'
from 'exp_send' when necessary. In the ActiveState port, we
were just more explicity in sticking to the exp_ naming for
examples. Both work just fine (on Windows or Unix).
> So, what is stopping me from simply using Expect when driving automated
> tests on ClearCase in a DOS Command Window. What is so special about
> Expect-For-Windows.
Now here I think you are a bit confused. Expect is what
provides the (exp_)spawn and (exp_)send commands, whichever
platform you are on. If you want to make use of those, you
require Expect.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
David Gravereaux
>I
>am interested in a Tcl solution to drive DOS Command Window application
>testing.
As I stated before, the difference between Expect's spawn channel and
Tcl's pipe channel regards how the application run under those pipes use
(or don't use) the actual console.
If the apps launched under the command prompt don't access the console,
pipes are sufficient and Expect is not required.
Here's an example:
C:\WINNT\system32>tclsh84
% set pipe [open |[string map {\\ /} $env(COMSPEC)] r+]
file90e9c8
% fconfigure $pipe -blocking 0 -buffering line -translation {lf crlf}
% read $pipe
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
C:\WINNT\system32>
% puts $pipe ipconfig
% read $pipe
ipconfig
Windows 2000 IP Configuration
Ethernet adapter LAN:
Connection-specific DNS Suffix . : speakeasy.net
IP Address. . . . . . . . . . . . : 192.168.0.100
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
C:\WINNT\system32>
Under the command prompt running in a pipe, telnet is *STILL* not an
acceptable application under a pipe as this shows:
% puts $pipe telnet
% read $pipe
telnet
C:\WINNT\system32>
% puts $pipe "echo %errorlevel%"
% read $pipe
echo %errorlevel%
-1
C:\WINNT\system32>
%
Irregardless of the channel type (spawn vs. pipe), if you want the
send/expect manner of programming that Expect provides, by all means use
it. If that method doesn't fit the style you want to program in, than use
simple pipes. But be aware that not all console subsystem character mode
Win32 apps can run in a pipe channel. Yet E4W can run those troublesome
apps with its spawn channel.
Do you _need_ Expect? I can't tell you that. That is a decision you have
to make. Even knowing that you might not need the capabilities of the
spawn channel that Expect provides, you still use Expect's programming
style giving it a pipe like this:
% log_user 0
1
% fconfigure $pipe -blocking 0 -buffering none -translation {lf crlf}
% exp_spawn -open $pipe
% exp_send "ipconfig\n"
% expect -re {Default Gateway(.*): (.*)\n} {exp_send_user
$expect_out(2,string)}
192.168.0.1
Victor Wagner
> I would like to thank all of you for your replies to my query.
> It would appear that I am not getting an answer to my direct question
> but a lot of suggestions on using Linux, older versions of
> expect-for-windows
> and the like.
> Just to refocus.....
> The application that I am trying to test MUST be tested in a Windows OS
> environment. Any attempt to test it through alternative approaches such as
> LINUX
> just doesn't provide a true test of the applications capabalities UNDER
> WINDOWS.
It is windows appication after all? You've written about DOS based app
and I thought that you need to testing it under DOS, using Windows just
as platform, capable of running DOS apps.
For DOS apps Linux dosemu, not to mention QEMU provides much more native
environment than Windows console.
WINE, of course "is not an emulator", and doesn't replace
not real Windows environment, but there are some case where you
can be sure, that if thing runs under Wine, it would run under any real
windows out there, because Wine implements just a common subset of
Windows API.
WINE is good way for automated testing windows apps, when they are
developed using cross compiler. You need to do manual testing under real
windows, but every time you change code, you run automated test suite
under wine, which saves you from continual jumping from one machine to
another.
There is also one additional way to use *nix expect to drive windows app
- use telnet server which comes with WinXP to login to windows machine
and drive telnet session using expect. Thus your app would run on real
Windows machine, but your test script would run on normal machine.
--
Never make any mistaeks.
-- Anonymous, in a mail discussion about to a kernel bug report
ouj
I am working on an embedded processor. Our group purchased the development
tools such as powerpc-eabi-gcc, powerpc-eabi-gdb, etc. from a company.
They cross-compiled using some version of cygwin. cygwin1.dll is also
bundled with their tools.
Now I need to automate the debugging of the powerpc-eabi-gdb in order to
test the hardware. I downloaded expect from the cygwin website. However,
powerpc-eabi-gdb complained that there is a different version of
cygwin1.dll exists and would not statt.
Then, I realize that I need some things NOT compiled from cygwin. I
downloaded Expect-for-Windows from ActiveState. That works very well. I
am going to purchase one license.
Here comes my question. Can I download the source code of expect from
cygwin and compile it using MinGW gcc so that the reliance on cygwin1.dll
can be eliminated?
Thanks a lot!
Best regards,
Jingzhao
David Gravereaux
>Here comes my question. Can I download the source code of expect from
>cygwin and compile it using MinGW gcc so that the reliance on cygwin1.dll
>can be eliminated?
MinGW builds native win32 executables using msvcrt.dll as the runtime.
The cygwin expect is quite dependant on the posix layer. You can try it,
but off-hand I don't think it will work.
Victor Wagner
: Here is my story with Expect for Windows.
: I am working on an embedded processor. Our group purchased the development
: tools such as powerpc-eabi-gcc, powerpc-eabi-gdb, etc. from a company.
: They cross-compiled using some version of cygwin. cygwin1.dll is also
: bundled with their tools.
: Now I need to automate the debugging of the powerpc-eabi-gdb in order to
As far as I know, you don't need expect to drive GDB. GDB is intended to
be driven programmatically. So it doesn't have buffering issues which
are primary need to use pseudo ttys.
I think that you can just
set f [open "|gdb $args" r+]
fconfigure $f -buffering none -blocking y
and use gets and puts to drive gdb.
--
Cameron Laird
Victor Wagner <vi...@45.free.net> wrote:
>ouj <o...@aludra.usc.edu> wrote:
.
.
.
>: Now I need to automate the debugging of the powerpc-eabi-gdb in order to
>
>As far as I know, you don't need expect to drive GDB. GDB is intended to
>be driven programmatically. So it doesn't have buffering issues which
>are primary need to use pseudo ttys.
>
>I think that you can just
>
>set f [open "|gdb $args" r+]
>fconfigure $f -buffering none -blocking y
>
>and use gets and puts to drive gdb.
>
>--
... and, if you are committed to [send]-[expect] conversations,
you can continue to write those in a pure-Tcl context with a
couple of "helper definitions" I've written in the past, but
don't have handy this morning. One of us can re-create them,
if there's enough interest ...
lvi...@gmail.com
According to Sid Pollock <pol...@nortelnetworks.com>:
:I actually want to "avoid" using Expect-for-Windows and just use "Expect"
:simply because we are not creating Window GUIs. We are simply executing
:commands in the DOS Command Prompt window. So your response:
Ah - here's a misunderstanding. The Expect for Windows is just Expect
for dos command prompt applications. It is NOT an expect for GUI applications.
The difference between Expect for Windows, the commercial package and
Expect the free package is that a variety of bugs and missing features
have been added. That's all.
--
<URL: http://wiki.tcl.tk/ > Whether it's Linux or blue cheese, I don't care.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@gmail.com > <URL: http://www.purl.org/NET/lvirden/ >
Victor Wagner
> According to Sid Pollock <pol...@nortelnetworks.com>:
> :I actually want to "avoid" using Expect-for-Windows and just use "Expect"
> :simply because we are not creating Window GUIs. We are simply executing
> :commands in the DOS Command Prompt window. So your response:
> Ah - here's a misunderstanding. The Expect for Windows is just Expect
> for dos command prompt applications. It is NOT an expect for GUI applications.
Really? I thought it is expect for Windows Console applications.
There is huge difference between these classes of applications.
For instance, tclsh84.exe from Active State Tcl is Windows Console
application. It can access registry, it can use Tcp/Ip networking, use
dde and so on. It is proper windows application. Just without GUI.
If you try to run this under proper DOS it won't run. Even WDOSX
extender wouldn't help. Especially if you attempt to package require
registry or dde.
To run Tcl under DOS you'll need my unofficial DJGPP port of Tcl.
Which obvoisly cannot access registry or DDE, and require additional emulation layer to access network when run under windows.
And it is yet not proper DOS application. It cannot run on 8088 machine
and need DPMI host when run under pure DOS.
If somebody port Tcl into DOS proper, this version would be unable to
deal with long filenames and would have severe memory limitations.
So, don't mix Win32 Console with DOS. They are quite distinct operating
environments.
--
It's not really a rule--it's more like a trend.
-- Larry Wall in <1997102217...@wall.org>
David Gravereaux
>> Ah - here's a misunderstanding. The Expect for Windows is just Expect
>> for dos command prompt applications. It is NOT an expect for GUI applications.
>
>Really? I thought it is expect for Windows Console applications.
>There is huge difference between these classes of applications.
It always weirds me out when people mention DOS, but really mean character
mode Win32 console not extended-mode DPMI, real-mode or whatever..
David Gravereaux
>vi...@45.free.net (Victor Wagner) wrote:
>
>>> Ah - here's a misunderstanding. The Expect for Windows is just Expect
>>> for dos command prompt applications. It is NOT an expect for GUI applications.
>>
>>Really? I thought it is expect for Windows Console applications.
>>There is huge difference between these classes of applications.
>
>It always weirds me out when people mention DOS, but really mean character
>mode Win32 console not extended-mode DPMI, real-mode or whatever..
The ActiveState E4W port can't work with DOS apps.. And I mean real
DOS-16 that need to run in the NTVDM. The way the NTVDM draws text to the
console window is from kernel mode which can't be caught by the intercept
method. Sad but true. For the test app, I was trying DJGPP's rhide.exe
debugger. The VDM does have some hooks, but none that allow the ability
to intercept any drawing calls. I can catch modules loading and unloading
and can even force load a dll into the VDM process. But there's one
mystery I wasn't able to solve... For all VDM processes, there always
exists a null.dll in the process.. I never figured out what that was,
where it came from or what it did.
Rufus V. Smith
<lvi...@gmail.com> wrote in message news:cj94sr$p4p$1...@srv38.cas.org...
>
>
> The difference between Expect for Windows, the commercial package and
> Expect the free package is that a variety of bugs and missing features
> have been added. That's all.
>
Nice of them to add some bugs.
As if Windows apps needed more.
Coals to Newcastle?
Rufus
David Gravereaux
>> The difference between Expect for Windows, the commercial package and
>> Expect the free package is that a variety of bugs and missing features
>> have been added. That's all.
>>
>
>Nice of them to add some bugs.
>
>As if Windows apps needed more.
HaHa.. Read that as.. variety of bugs eliminated and missing features
added
ouj
I just tried and suceeded! I am very interested in your script. Is there
any thing I can help to recreate them? I am trying to do it myself at the
same time.
Thanks a lot! I love Tcl/Tk!!! They are so amazing!
Best regards,
Jingzhao