Compile expect 5.38 in MinGW
Chang Li
I have tried it. But many .h files are lacked, such as sys/ioctl.h,
_ansi.h.
I am not sure if it is possible to compile Expect in MinGW
since there are many Unix special features in expect.
Is Expect POSIX compatible?
Chang
Michael Schlenker
> Anybody has tried to compile latest expect 5.38 in MinGW?
> I have tried it. But many .h files are lacked, such as sys/ioctl.h,
> _ansi.h.
>
> I am not sure if it is possible to compile Expect in MinGW
> since there are many Unix special features in expect.
A working up-to-date windows expect isn't anywhere to be seen (unless
someone drops a large enough amount of cash on the table and finds
someone to do the job).
It may be possible to compile expect with MinGW as a cross compile for
unix platforms, but native Windows expect is a no go at the moment.
Michael Schlenker
David Gravereaux
>I am not sure if it is possible to compile Expect in MinGW
>since there are many Unix special features in expect.
True. MinGW is a gcc compiler to build native windows executables. It can't
the stock Expect. This was the reason for the large and unfinished source
changes in the telco-tech-win32-take2-branch on CVS to enable the feature of
interacting with a console. Because M$ didn't give us this ability... force it
using evil techniques of running the child in a debugger, set breakpoints on
interesting WinAPI calls the child makes (of the ones possible), inject UI
events like keypress and mouse moves, and let Expect sit in the middle of that.
As windows developers are constant reminded, mswindows is not posix.
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway(western spiral arm),alpha sector]
Chang Li
"Michael Schlenker" <sch...@uni-oldenburg.de> wrote in message
news:b6q6s2$7pc47$1...@ID-102549.news.dfncis.de...
> A working up-to-date windows expect isn't anywhere to be seen (unless
> someone drops a large enough amount of cash on the table and finds
> someone to do the job).
> It may be possible to compile expect with MinGW as a cross compile for
> unix platforms, but native Windows expect is a no go at the moment.
>
How about work in the MSYS? The lack of the .h files is the problem of MinGW
not Windows.
Chang
> Michael Schlenker
>
>
>
Don Libes
> I am not sure if it is possible to compile Expect in MinGW
> since there are many Unix special features in expect.
> Is Expect POSIX compatible?
POSIX doesn't address several things that Expect needs such as ptys.
So it's rather pointless to ask for POSIX compatibility. This is
covered in more detail (along with many other interesting stories) in:
http://expect.nist.gov/doc/seven-years.html
Don
Benjamin Riefenstahl
"Chang Li" <cha...@neatware.com> writes:
> How about work in the MSYS? The lack of the .h files is the problem
> of MinGW not Windows.
[Please somebody correct me, if I am wrong with any of this.]
The lack of _functionality_ like documented pseudo-ttys is a problem
that makes a pure Windows Expect difficult. Cygwin provides those
features on top of Windows but that means that programs that want to
use those features must be compiled with Cygwin. (MSYS is just a
dumbed-down version of Cygwin for executing configure scripts.)
OTOH for Cygwin programs you usually have source anyway, and a lot of
them are scriptable by design. So the need for Expect is not very big
for Cygwin programs, I'd imagine. I'd think that most of the time you
want to script programs with Expect on Windows, it would be
closed-source Windows programs, but these are usually not built with
Cygwin.
so long, benny
Chang Li
"Benjamin Riefenstahl" <Benjamin.R...@epost.de> wrote in message
news:m34r5ag...@cicero.benny.turtle-trading.net...
> Hi Chang, everybody,
Anybody has the expect 5.38 source that could compile on MinGW or Cygwin?
> The lack of _functionality_ like documented pseudo-ttys is a problem
> that makes a pure Windows Expect difficult. Cygwin provides those
> features on top of Windows but that means that programs that want to
> use those features must be compiled with Cygwin. (MSYS is just a
> dumbed-down version of Cygwin for executing configure scripts.)
>
If ptys is the main problem it may be not too difficult to implement on
Windows.
At least in the DOS console mode Windows is well similar to Unix.
> OTOH for Cygwin programs you usually have source anyway, and a lot of
> them are scriptable by design. So the need for Expect is not very big
> for Cygwin programs, I'd imagine. I'd think that most of the time you
> want to script programs with Expect on Windows, it would be
> closed-source Windows programs, but these are usually not built with
> Cygwin.
There are three ways to make Expect work on Windows
1. Use MinGW or Cygwin
2. Use Expect port from 5.38 for Windows
3. Use Expect port from 5.21 for Windows but work along with Tcl 8.4
The first way can make Expect as a stand along application on Windows
but may not work with other extensions on Windows (? ). The second way
is ideal situation but there are many difficults. The third way is the
upgrade
from old version to new Tcl version.
Which way is better?
Chang
>
>
> so long, benny
David Gravereaux
>Which way is better?
cvs -d :pserver:anon...@cvs.expect.sf.net:/cvsroot/expect checkout -r
telco-tec-win32-take2-branch
Just finish it and make a channel driver for the ConsoleDebugger C++ class.
Then you can build it with MinGW.
David Gravereaux
>The lack of the .h files is the problem of MinGW
>not Windows.
Actually, that's not true. It would be an easy situation to solve if that was
the case in and of itself.
For example, [1] where in the windows console API is a console expressed as a
pure stream?
Not anywhere. WriteConsoleOutputCharacter, WriteConsoleOutputAttribute and
SetConsoleCursorPosition (to name a few) are all separate. Wouldn't it be nice
if a windows console could take VT100 or ANSI terminal codes in the raw?
[2] Then, how can those streams be "filtered" (a/k/a man-in-the-middle)?
See the first question...
David Gravereaux
For anyone still monitoring this thread, here's the big picture as I see it...
First, the windows Expect port on http://sf.net/projects/expect can and does
work with already open channels such as pipes and serial ports -- The OS neutral
aspect. What is missing is the ability to spawn a console application and turn
that child's calls to its console into a stream (a Tcl channel at the end-point)
that Expect can work with. This feature is NOT provided by the windows API.
The only way I see to enable this is to run the child in the system debugger and
catch all calls it makes to the console API. It's very evil, but does work, and
works with all Win32 console applications as opposed to cygwin's Expect port
which only works with the cygwin tools because it has insider knowledge of
itself to get around this limitation.
All that lo-level work is done -- surprise! The Expect port just needs a
channel driver interface to the ConsoleDebugger C++ class.
It's not a matter of some missing header files, really. Although, you can
interpoll from "missing .h files" to "must be missing functions" which leads to
"has to be missing features in the OS because there are no maps".
For example, you can try this at home, create a console application that writes
to stdout [WriteFile(GetStdHandle(STD_OUTPUT_HANDLE)...)]. That's easy to
catch, just use pipes to get the output. Next, write to the console instead
[WriteConsoleOutputCharacter(...)]. How do you catch that? That's the problem,
not some missing header files.
Chang Li
"David Gravereaux" <davy...@pobox.com> wrote in message
news:0uej9v4qrodhpjldh...@4ax.com...
> "Chang Li" <cha...@neatware.com> wrote:
>
[...]
> For example, you can try this at home, create a console application that
writes
> to stdout [WriteFile(GetStdHandle(STD_OUTPUT_HANDLE)...)]. That's easy to
> catch, just use pipes to get the output. Next, write to the console
instead
> [WriteConsoleOutputCharacter(...)]. How do you catch that? That's the
problem,
> not some missing header files.
Have to use the API Interception.
Chang
David Gravereaux
>
>"David Gravereaux" <davy...@pobox.com> wrote in message
>news:0uej9v4qrodhpjldh...@4ax.com...
>> "Chang Li" <cha...@neatware.com> wrote:
>>
>[...]
>
>> For example, you can try this at home, create a console application that
>writes
>> to stdout [WriteFile(GetStdHandle(STD_OUTPUT_HANDLE)...)]. That's easy to
>> catch, just use pipes to get the output. Next, write to the console
>instead
>> [WriteConsoleOutputCharacter(...)]. How do you catch that? That's the
>problem,
>> not some missing header files.
>
>Have to use the API Interception.
See win/ConsoleDebugger.cpp, it does that. Somewhat mystical in its method...
http://cvs.sf.net/cgi-bin/viewcvs.cgi/expect/expect/win/Attic/expWinConsoleDebugger.hpp?rev=1.1.2.29&only_with_tag=telco-tec-win32-take2-branch&content-type=text/vnd.viewcvs-markup
http://cvs.sf.net/cgi-bin/viewcvs.cgi/expect/expect/win/Attic/expWinConsoleDebugger.cpp?rev=1.1.2.31&only_with_tag=telco-tec-win32-take2-branch&content-type=text/vnd.viewcvs-markup
http://cvs.sf.net/cgi-bin/viewcvs.cgi/expect/expect/win/Attic/expWinConsoleDebuggerBreakPoints.cpp?rev=1.1.2.15&only_with_tag=telco-tec-win32-take2-branch&content-type=text/vnd.viewcvs-markup