Expect in Active TCL.
Ravikumar Eswaran
Is Expect not part of ActiveTCL 8.4.1?? I am lookign for Expect for
Windows. How can I get it?
Regards,
Ravikumar Eswaran.
Jeffrey Hobbs
> Is Expect not part of ActiveTCL 8.4.1?? I am lookign for Expect for
> Windows. How can I get it?
There is no official expect port for Windows. There is an old, unofficial
version, but it is tied to Tcl 8.0. Any attempts at getting a funding
effort going for an up-to-date port have been unsuccessful so far.
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Cameron Laird
Jeffrey Hobbs <Je...@ActiveState.com> wrote:
>Ravikumar Eswaran wrote:
>> Is Expect not part of ActiveTCL 8.4.1?? I am lookign for Expect for
>> Windows. How can I get it?
>
>There is no official expect port for Windows. There is an old, unofficial
>version, but it is tied to Tcl 8.0. Any attempts at getting a funding
>effort going for an up-to-date port have been unsuccessful so far.
.
.
More details are generally available at
<URL: http://wiki.tcl.tk/ExpectForWindows >.
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://phaseit.net/claird/home.html
marsd
> Ravikumar Eswaran wrote:
> > Is Expect not part of ActiveTCL 8.4.1?? I am lookign for Expect for
> > Windows. How can I get it?
>
> There is no official expect port for Windows. There is an old, unofficial
> version, but it is tied to Tcl 8.0. Any attempts at getting a funding
> effort going for an up-to-date port have been unsuccessful so far.
EFW=expect for windows.
I asked about this once before, but seriously now...
I get the impression that the work involved would be monumental
and would include creating interfaces to windows processes that
don't even exist in the API, or were explicitly non-designed.
I've looked at the windows api and decided it was so bad and so
closed that it was a waste of my time. Still I would contribute
a few dollars to this cause if I thought it wasn't lost and I'm sure
there are a few other sysadmins who would do the same.
But really, could I call EFW for all tcl malleable processes on win32?
I sincerely wonder, and I wonder what the benefit would be.
What would the docs look like? Is Don Libes going to write another
invaluable book on the windows version?
Forgive me for being skeptical, and I appreciate the incredible work
being done on tclWIN32 but isn't EFW a lost cause?
David Gravereaux
>But really, could I call EFW for all tcl malleable processes on win32?
>I sincerely wonder, and I wonder what the benefit would be.
Only console processes that (hopefully) don't get too crazy with
CreateConsoleScreenBuffer() and switch around much. That would get sticky with
the handle following and redrawing.
What it definitely won't do is trap a dos application. dos-16 applications get
loaded into the ntvdm and where the win32 drawing translations are made is not
in user-mode, so that bypasses the break-points... Oh well.
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway,alpha sector]
David Gravereaux
>I get the impression that the work involved would be monumental
>and would include creating interfaces to windows processes that
>don't even exist in the API, or were explicitly non-designed.
True! Development time is the way to solve it, but time usually equals money.
I worked on EFW lo-level stuff a ways back. Anyone taking it on seriously would
have a great point to continue from. I'd prefer to spend my hobby time on
programming projects I consider more fun, sorry..
David Gravereaux
https://sourceforge.net/project/shownotes.php?release_id=96583
https://sourceforge.net/project/showfiles.php?group_id=13179&release_id=96583
All it needs is a custom channel driver to hook the code into expect.dll
The last I left off on was playing with the concept of [interact] at the API
level. What a brain twist :) Good luck.
Cameron Laird
marsd <nomob...@hotmail.com> wrote:
.
.
.
>But really, could I call EFW for all tcl malleable processes on win32?
>I sincerely wonder, and I wonder what the benefit would be.
>
>What would the docs look like? Is Don Libes going to write another
>invaluable book on the windows version?
>Forgive me for being skeptical, and I appreciate the incredible work
>being done on tclWIN32 but isn't EFW a lost cause?
Suppose some combination of us pull ourselves together and
complete EFW in a technical sense: how much incremental
value would there be in a book which focuses on EFW? Would
it matter if someone other than wrote it? Should such a book
do only EFW, or cover both Windows and Unix?
No, I am not asking idly.
marsd
> nomob...@hotmail.com (marsd) wrote:
>
> >But really, could I call EFW for all tcl malleable processes on win32?
> >I sincerely wonder, and I wonder what the benefit would be.
>
> Only console processes that (hopefully) don't get too crazy with
> CreateConsoleScreenBuffer() and switch around much. That would get sticky with
> the handle following and redrawing.
You are referring to Duplicatehandle() and inheritance here, or just
maintaining a buffer pool for multiple processes and calling Set
ConsoleActiveScreenBuffer()? The latter doesn't seem like it would be
a huge problem, but with windows who knows.
How are the security attributes for lpSecurityAttributes handled in
Windows XP? Is NULL still valid or must there be a "real" descriptor?
>
> What it definitely won't do is trap a dos application. dos-16 applications get
> loaded into the ntvdm and where the win32 drawing translations are made is not
> in user-mode, so that bypasses the break-points... Oh well.
Thanks for the info..so what you are saying is that there would
have to be a different version , or perhaps a 16 bit compat loadable
to emulate expects functionality for 16 bit dos based apps, or that
such
an undertaking is futile?
Am I right in assuming that some of the little perks users like
about expect on *nix, traditionally *nix style things like signal
handling, fork(), etc..would not be attempted for obvious reasons?
David Gravereaux
>David Gravereaux <davy...@pobox.com> wrote in message news:<ct3ruu0hjkbv8nqbq...@4ax.com>...
>> nomob...@hotmail.com (marsd) wrote:
>>
>> >But really, could I call EFW for all tcl malleable processes on win32?
>> >I sincerely wonder, and I wonder what the benefit would be.
>>
>> Only console processes that (hopefully) don't get too crazy with
>> CreateConsoleScreenBuffer() and switch around much. That would get sticky with
>> the handle following and redrawing.
>
>You are referring to Duplicatehandle() and inheritance here, or just
>maintaining a buffer pool for multiple processes and calling Set
>ConsoleActiveScreenBuffer()?
Worse, tracking multiple screens in the debuggee (yes, slaves are run in a
debugger) and handling the redraws by using the injector.dll to call a set of
console APIs such that those are then trapped by the debugger so we can now get
the contents of the buffer switched to. A multi-part exchange.
> The latter doesn't seem like it would be
>a huge problem, but with windows who knows.
>How are the security attributes for lpSecurityAttributes handled in
>Windows XP? Is NULL still valid or must there be a "real" descriptor?
None. The debugger as full access.
>>
>> What it definitely won't do is trap a dos application. dos-16 applications get
>> loaded into the ntvdm and where the win32 drawing translations are made is not
>> in user-mode, so that bypasses the break-points... Oh well.
>
>Thanks for the info..so what you are saying is that there would
>have to be a different version , or perhaps a 16 bit compat loadable
>to emulate expects functionality for 16 bit dos based apps, or that
>such
>an undertaking is futile?
Futile to my eyes, but i'm sure there is someone around that might know the
tricks with vdd coding.
>Am I right in assuming that some of the little perks users like
>about expect on *nix, traditionally *nix style things like signal
>handling, fork(), etc..would not be attempted for obvious reasons?
windows does things like windows does and trying to force it into a unix model
at times can miss the target quite severely. Yes, windows has signals. We can
group them in 2 categories.
1) received by a console handler routine (see SetConsoleCtrlHandler). The
signals are:
CTRL_C_EVENT
CTRL_BREAK_EVENT
CTRL_CLOSE_EVENT
CTRL_LOGOFF_EVENT
CTRL_SHUTDOWN_EVENT
2) death by exception status:
EXCEPTION_ACCESS_VIOLATION
EXCEPTION_DATATYPE_MISALIGNMENT
EXCEPTION_ARRAY_BOUNDS_EXCEEDED
EXCEPTION_FLT_DENORMAL_OPERAND
EXCEPTION_FLT_DIVIDE_BY_ZERO
EXCEPTION_FLT_INEXACT_RESULT
EXCEPTION_FLT_INVALID_OPERATION
EXCEPTION_FLT_OVERFLOW
EXCEPTION_FLT_STACK_CHECK
EXCEPTION_FLT_UNDERFLOW
EXCEPTION_INT_DIVIDE_BY_ZERO
EXCEPTION_INT_OVERFLOW
EXCEPTION_PRIV_INSTRUCTION
EXCEPTION_IN_PAGE_ERROR
EXCEPTION_ILLEGAL_INSTRUCTION
EXCEPTION_NONCONTINUABLE_EXCEPTION
EXCEPTION_STACK_OVERFLOW
EXCEPTION_INVALID_DISPOSITION
EXCEPTION_GUARD_PAGE
EXCEPTION_INVALID_HANDLE
CONTROL_C_EXIT
Notice that EXCEPTION_FLT_DIVIDE_BY_ZERO looks like SIGFPE, but wasn't sent to
the handler routine prior to death.
marsd
> In article <6358834.02120...@posting.google.com>,
> marsd <nomob...@hotmail.com> wrote:
> .
> .
> .
> >But really, could I call EFW for all tcl malleable processes on win32?
> >I sincerely wonder, and I wonder what the benefit would be.
> >
> >What would the docs look like? Is Don Libes going to write another
> >invaluable book on the windows version?
> >Forgive me for being skeptical, and I appreciate the incredible work
> >being done on tclWIN32 but isn't EFW a lost cause?
>
> Suppose some combination of us pull ourselves together and
> complete EFW in a technical sense: how much incremental
> value would there be in a book which focuses on EFW? Would
> it matter if someone other than wrote it? Should such a book
> do only EFW, or cover both Windows and Unix?
>
> No, I am not asking idly.
Well my question was based on a pipedream anyway..that
EFW would have the same hooks into windows that it does
into *nix flavors now..In that case it would have a lot
of value because you have a radically different environ-
ment to work with and some new innovation and explanation
would probably be in order.
A real hangup seems to me that inevitably people would want to
drive dos based apps, and if I didn't misunderstand DG this would
be a big problem.
Helmut Giese
>A real hangup seems to me that inevitably people would want to
>drive dos based apps, and if I didn't misunderstand DG this would
>be a big problem.
written when Windows was 16 bit, that is Windows 3.1. Ok, you could
write them even today if you wanted to, but who would?
Anyway, getting Expect to work with (32 bit) console mode apps would
already be a big step ahead.
Helmut Giese
Cameron Laird
>> it matter if someone other than wrote it? Should such a book
>> do only EFW, or cover both Windows and Unix?
>>
>> No, I am not asking idly.
>
>
>Well my question was based on a pipedream anyway..that
>EFW would have the same hooks into windows that it does
>into *nix flavors now..In that case it would have a lot
>of value because you have a radically different environ-
>ment to work with and some new innovation and explanation
>would probably be in order.
>
>A real hangup seems to me that inevitably people would want to
>drive dos based apps, and if I didn't misunderstand DG this would
>be a big problem.
Help me understand Windows-think. In Unix terms,
Expect is simply necessary; administrators *must*
have it because of the broken interfaces of passwd
and many other legacy character-based applications
and utilities. Expect also provides conveniences
for other situations ...
Is EFW simply something pleasant and nice to have,
or do you see it as comparably indispensable? To
be blunt, my impression of character-based Win*
applications is that they are so broken that people
do without them already, and/or so broken taht
Expect doesn't have a reasonable chance of mollify-
ing them into programmability. EFW's biggest value
is just in making Win* desktops convenient command
centers for Expect-ing out to *other* hosts--but
the pure-Tcl telnet does almost all of that already.
David Gravereaux
>Is EFW simply something pleasant and nice to have,
>or do you see it as comparably indispensable?
Cameron,
I know you're addressing marsd, but I feel opportunity to speak.
When I think SSH on windows, I think of GUI applications like SecureCRT
(r) by VanDyke Technologies. If I want a commandline one, I use cygwin's
SSH. Luckily, cygwin's SSH works with cygwin's Export port.
Many years ago I did some temp work for a cell phone company. I think it
was the qualcomm flasher that was a Win32 console mode application --
drop-down lists, dialogs, the works, in old dos style. You just don't see
these much anymore. My job wasn't to automate the process of reflashing,
but Expect would have been the tool to choose for automating the
text/keypress entry.
The problem with the cygwin port of Expect is that it only works with the
cygwin tools. This leaves native console apps in the dark.
But, to me, a darkness that's always been there.
There is the terminal service, which addresses a similar function of
running an application remotely. I've never looked into how it works and
can't comment if the way EFW works by running the slave in a debugger and
trapping all the console API calls is similar or if the terminal service
has it's own OS hooks that Expect should be using instead.
> To
>be blunt, my impression of character-based Win*
>applications is that they are so broken that people
>do without them already, and/or so broken taht
>Expect doesn't have a reasonable chance of mollify-
>ing them into programmability.
I think it can be done. Yeah, Win2K's included telnet.exe has one *dumb*
mistake I know of, but it's workable. TUI just seems to be gone on Win32,
but not because it can't be done. Interestingly, I don't know of any C++
TUI windowing libraries for Win32 besides Borland's discontinued Turbo
Vision. Xterminal, a nice windowing library that sits on top of ncurses
and gpm (for mouse events) would require a major porting effort to work on
Win32.
> EFW's biggest value
>is just in making Win* desktops convenient command
>centers for Expect-ing out to *other* hosts--but
>the pure-Tcl telnet does almost all of that already.
The Expect-Win32 binary @
http://sourceforge.net/project/showfiles.php?group_id=13179&release_id=66209
can expect upon already open channels, but spawn for trapping a slave
doesn't work.
marsd
That's why I believe(d) that a successful expect for windows
would have to be able to incorporate some elements of tcl
that already exist for communicating with win32 processes,
(COM, for instance), and provide an abstraction model for
dealing with graphical as well as console based apps.
With even primitive communication with "true" console
(16 bit dos based) apps very difficult or impossible, and
the majority of windows apps without cli visibility, what's
the point of EFW nunless it does things in a totally
different way?
Then you would need a new expect book to explain all the new
functionality, methods, and interfaces.
Like I said, a pipe dream. It would be a really unhappy process
to even get the original model to work half-decently, much less
develop a true windows aware expect.
As afar as indispensable..No..the graphical environment is dummied
down to the point of absurdity. Why would you NEED expect to mediate
for you?
Would it be nice to be able to have EFW open explorer, browse to
c:\mybadpics and "arrange by size", or drive IEXPLORE and
open http://windowsupdate, automating the download of the newest security
patches..yeah, it would be nice to have a pseudo familiar automation
interface to do these things with, but far from critical.
Cameron Laird
>would have to be able to incorporate some elements of tcl
>that already exist for communicating with win32 processes,
>(COM, for instance), and provide an abstraction model for
>dealing with graphical as well as console based apps.
>
>With even primitive communication with "true" console
>(16 bit dos based) apps very difficult or impossible, and
>the majority of windows apps without cli visibility, what's
>the point of EFW nunless it does things in a totally
>different way?
>
>Then you would need a new expect book to explain all the new
>functionality, methods, and interfaces.
>
>Like I said, a pipe dream. It would be a really unhappy process
>to even get the original model to work half-decently, much less
>develop a true windows aware expect.
>
>As afar as indispensable..No..the graphical environment is dummied
>down to the point of absurdity. Why would you NEED expect to mediate
>for you?
>Would it be nice to be able to have EFW open explorer, browse to
>c:\mybadpics and "arrange by size", or drive IEXPLORE and
>open http://windowsupdate, automating the download of the newest security
>patches..yeah, it would be nice to have a pseudo familiar automation
>interface to do these things with, but far from critical.
Good details. Thanks.
My summary: EFW isn't going to happen. It's expensive,
and few Windows users would appreciate its value.
lvi...@yahoo.com
According to marsd <nomob...@hotmail.com>:
:A real hangup seems to me that inevitably people would want to
:be a big problem.
the other expectation that I would think people would have is that they
would be able to use expect with GUI applications, but Expect itself
doesn't deal in that domain.
--
Tcl - The glue of a new generation. <URL: http://wiki.tcl.tk/ >
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
David Gravereaux
>With even primitive communication with "true" console
>(16 bit dos based) apps very difficult or impossible, and
>the majority of windows apps without cli visibility, what's
>the point of EFW nunless it does things in a totally
>different way?
Please be careful with your definition of terms, here. A "true" console
application might be more correctly labeled as a Win32/64 executable with
its subsystem bit in the PE header set to IMAGE_SUBSYSTEM_WINDOWS_CUI.
netstat.exe, nslookup.exe, net.exe, route.exe, tracert.exe, and ftp.exe
would all be examples. Win2K's telnet.exe happens to be a bit special as
it supports color/screens/cursor movement and is more "true" console with
its usage of the console API than the others listed.
DOS isn't always character mode and "legacy" might be a better term to
group them. Some DOS-16 utilities are included in NT still; see debug.exe
and edline.exe ;)
Yes, it is unfortunate that windows' DOS emulator subsystem (NTVDM)
doesn't appear to allow hooking into the display output stream from
user-mode. Solutions to this issue might be found in the handicap
facilities or the terminal service, as a guess, should someone feel like
doing some research..
marsd
> nomob...@hotmail.com (marsd) wrote:
>
> >With even primitive communication with "true" console
> >(16 bit dos based) apps very difficult or impossible, and
> >the majority of windows apps without cli visibility, what's
> >the point of EFW nunless it does things in a totally
> >different way?
>
> Please be careful with your definition of terms, here. A "true" console
Right you are, thanks for the correction.
David Gravereaux
Sorry, I didn't mean to be harsh with my reply. There's just so much
detail in the method of capturing console events that the windows OS just
wasn't designed to do.
Take a DOS character mode app that assumes direct memory access to the VGA
registers ->
// Displays a string on the screen, assuming a 80x25 color adapter.
void OnScreen(int x, int y, char *pszText, int nAttr)
{
char *pScreen = (char *) (0xb8000 + y * 160 + x * 2);
while (*pszText)
{
*pScreen++ = *pszText++;
*pScreen++ = nAttr;
}
}
0xb8000 is the base address for the screen. One writes directly to that
range to display test. Each character has an attribute code associated
with it, too. Some bit mask in the attribute code means blink. Win32
consoles don't have a blink attribute, but some how they do blink when the
DOS character is set to. The ntvdm appears to be smart about that.
Just how lo-level would a method for hooking into this need to go? Where
the ntvdm calls out to draw to the console is not from user-mode. Because
of that, the "console api debugger" hook method is rendered useless.
http://msdn.microsoft.com/library/en-us/other/hh/other/vddfn_1x2j.asp
"The provided VDM has built-in support for commonly used hardware such as
serial communication ports, video, mouse, and keyboard. Consequently, you
should not need a VDD to virtualize access to these common devices."
Sorry... not true for me. I need the hooks that the system does not
provide. Do I rewrite the video access parts to implement a hook facility
so I can capture screen drawing? What about the DOS interrupt 21h
services, too? Should I bother? Do I care? Are people still using DOS
because of U.S. government policy and stuck with an ancient acceptance
rule dating back to 1983?
At least with Win32 console apps, we can capture everything. What the
lo-level expect code should do with all that is the important part and how
to manage [interact] with keys and mouse, as well.
Anyone stuck with DOS apps they need to Except upon might consider Linux
with a dos emulator for that purpose. Would that work? I want to know.
Would a native Win32 console application running under WINE in Linux be
capturable by Expect built for Linux. I want to see that :)
marsd
> nomob...@hotmail.com (marsd) wrote:
>
> >David Gravereaux <davy...@pobox.com> wrote in message news:<crvevukhcnpnpga56...@4ax.com>...
> >> nomob...@hotmail.com (marsd) wrote:
> >>
> >> >With even primitive communication with "true" console
> >> >(16 bit dos based) apps very difficult or impossible, and
> >> >the majority of windows apps without cli visibility, what's
> >> >the point of EFW nunless it does things in a totally
> >> >different way?
> >>
> >> Please be careful with your definition of terms, here. A "true" console
> >> application might be more correctly labeled as a Win32/64 executable...
> >
> >Right you are, thanks for the correction.
>
> Sorry, I didn't mean to be harsh with my reply. There's just so much
> detail in the method of capturing console events that the windows OS just
> wasn't designed to do.
You weren't. I've been to comp.lang.c ;)
>
> "The provided VDM has built-in support for commonly used hardware such as
> serial communication ports, video, mouse, and keyboard. Consequently, you
> should not need a VDD to virtualize access to these common devices."
>
> Sorry... not true for me. I need the hooks that the system does not
> provide. Do I rewrite the video access parts to implement a hook facility
> so I can capture screen drawing?
This is a concrete example of a need to invent an interface that is
not documented and not designed in windows..How do other people that
deal with these shortfalls design around this, if they do?
> Anyone stuck with DOS apps they need to Except upon might consider Linux
> with a dos emulator for that purpose. Would that work? I want to know.
> Would a native Win32 console application running under WINE in Linux be
> capturable by Expect built for Linux. I want to see that :)
I'll try with dosemu and let you know.
David Gravereaux
>> Sorry... not true for me. I need the hooks that the system does not
>> provide. Do I rewrite the video access parts to implement a hook facility
>> so I can capture screen drawing?
>
>This is a concrete example of a need to invent an interface that is
>not documented and not designed in windows..How do other people that
>deal with these shortfalls design around this, if they do?
No clue.. A number of years ago I read from a mailing list a tale of a
firewall developer going a bit batty over NDIS layered network drivers and
the lack of having the proper hooks to do what he needed. Or was it too
much info he had to filter? Today, MS has an API for software firewalls.
I don't know the details of it.
For me, fighting with the windows OS for all it's weird behaviors has
become an art -- an art in acceptance and how to make things work. No
problem.. that's the secret. If one starts coding in unix style and
wonders why windows is so awful, one need to switch gears and stop
fighting it.
Take winsock for example.. For backward compatibility, select() is
included. But don't use it, please, it's a massive performance hit. For
best performance, the IOCP model is best. You pre-queue a ready buffer
before an event happens and the operation is handled entirely in kernel
mode of the LSP. Yes, it isn't 100% BSD sockets at this point, and the
handling of out-of-order completions along with thread syncing are a bit
complicated, but that's the windows way. It sure beats dropped FD_ACCEPT
notifications due to internal buffer over-runs which linux wouldn't do.
At a high enough load with select(), winsock will totally lock up due to
all the buffer overruns and unreclaimed internal resources.
>> Anyone stuck with DOS apps they need to Except upon might consider Linux
>> with a dos emulator for that purpose. Would that work? I want to know.
>> Would a native Win32 console application running under WINE in Linux be
>> capturable by Expect built for Linux. I want to see that :)
>
>I'll try with dosemu and let you know.
A good example of a DOS character mode app is the djgpp RHIDE debugger ->
ftp://gatekeeper.dec.com/pub/micro/pc/simtelnet/gnu/djgpp/v2apps/rhid149b.zip
http://www.delorie.com/djgpp/
I can send key and mouse events to it just fine, but can't get screen
drawing as per the reasons described earlier. The only user-mode call I
get is SetConsoleCursorPosition() :(