definitive answer requested regarding expect on Windows XP
Kim Letkeman
to imply something like this:
1) There was an excellent, but completely non-upward-compatible port of
Expect to Windows NT 4 way back when. It runs great on Windows NT if you
don't mind the inability to move forward on the TCL and Tk implementations.
2) This NT port does not run on Windows XP and some guy out there is trying
to do a better native port, but it's really hard -- his words.
3) There is a version of Expect in the Cygwin distribution, which apparently
does run on XP, but has some problems.
My own experience is that the version of Expect in the Cygwin distribution
immediately fries on even the simplest puts because it can't find the stdout
channel, whatever that means (I'm just trying to find a version to work with
on Windows XP and have no prior experience with the package.)
So ... is there a definitive answer out there? Is there a modern version of
Expect that I can use on Windows XP? Does the Cygwin version work reasonably
well? I'd really like to use it to animate out products over telnet.
Note: I work with people who tell me that Expect is torture to use and that
I should use Perl or Java. I would like the opportunity to judge for myself,
but so far things don't appear to be very pretty in the TCL / Expect world
on Windows XP.
Thanks.
Cameron Laird
Kim Letkeman <kim.le...@rogers.com> wrote:
>I've seen a couple of articles on this group regarding Windows XP. They seem
>to imply something like this:
.
.
>Note: I work with people who tell me that Expect is torture to use and that
>I should use Perl or Java. I would like the opportunity to judge for myself,
>but so far things don't appear to be very pretty in the TCL / Expect world
>on Windows XP.
>
>Thanks.
>
>
>
People say all sorts of things.
No, Expect on XP is not polished.
What's your need for Expect on XP? For the things Expect
does, it's MUCH easier (and more reliable) to use than
its Java or Perl correspondents. If the job is one that
can be readily done with Java or Perl, though, it's likely
that you don't need full Expect, and can instead rely on a
"pure-Tcl" version that might be more familiar to you.
So: what do you *really* want?
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Roy Terry
>
> I've seen a couple of articles on this group regarding Windows XP. They seem
> to imply something like this:
>
> 1) There was an excellent, but completely non-upward-compatible port of
> Expect to Windows NT 4 way back when. It runs great on Windows NT if you
> don't mind the inability to move forward on the TCL and Tk implementations.
I've used this "Chaffe" port on NT 4 and it works quite well.
> 2) This NT port does not run on Windows XP and some guy out there is trying
> to do a better native port, but it's really hard -- his words.
Don't know and don't have XP to try. Best suggestion is to get
the NT port and try it on XP. It comes with a bare-bones telnet.exe that
is sufficient for automation use. Seems to me fairly likely it will
still
work at least with this supplied telnet.
>
> 3) There is a version of Expect in the Cygwin distribution, which apparently
> does run on XP, but has some problems.
Best to stay away unless you're a unix architecture wizard and wish to
pioneer.
...
> So ... is there a definitive answer out there? ...
The definitive answer really will come from you trying it out I think.
>
> Note: I work with people who tell me that Expect is torture to use and that
> I should use Perl or Java.
Expect is torture for those who haven't/won't take time to appreciate
the
subtleties of the problems it is addressing and to read the docs
carefully.
If you approach it thoughtfully you'll see it is an amazingly powerful
program :-)
Roy (who likes using expect) Terry
Please post findings here.
lvi...@yahoo.com
According to Kim Letkeman <kim.le...@rogers.com>:
:I've seen a couple of articles on this group regarding Windows XP. They seem
:to imply something like this:
:
:1) There was an excellent, but completely non-upward-compatible port of
:Expect to Windows NT 4 way back when. It runs great on Windows NT if you
:don't mind the inability to move forward on the TCL and Tk implementations.
I am not certain what 'non-upward-compatible' means in your mind. Surely
I would have probably have called it an 'unsupported port' of Expect.
:2) This NT port does not run on Windows XP and some guy out there is trying
:to do a better native port, but it's really hard -- his words.
The 'some guy' was David Gravereaux <davy...@pobox.com>...
:My own experience is that the version of Expect in the Cygwin distribution
:immediately fries on even the simplest puts because it can't find the stdout
:channel, whatever that means (I'm just trying to find a version to work with
:on Windows XP and have no prior experience with the package.)
Perhaps if someone documents those problems and reports them, the problems
could be fixed?
A "stdout channel" is an open file associated with a program so that the
program can produce output.
:So ... is there a definitive answer out there? Is there a modern version of
:Expect that I can use on Windows XP?
I am not aware of a version that you can use.
:Note: I work with people who tell me that Expect is torture to use and that
:I should use Perl or Java. I would like the opportunity to judge for myself,
:but so far things don't appear to be very pretty in the TCL / Expect world
:on Windows XP.
I find Perl and Java to be a torture to use, myself. Particularly when
trying to automate other programs.
However, I also find Windows to be a torture to use, so I don't do it often.
--
Support Internet Radio <URL: http://saveinternetradio.org/ >
Join Tcl'2002 in Vancouver http://www.tcl.tk/community/tcl2002/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Chang Li
> I've seen a couple of articles on this group regarding Windows XP. They seem
> to imply something like this:
>
> 1) There was an excellent, but completely non-upward-compatible port of
> Expect to Windows NT 4 way back when. It runs great on Windows NT if you
> don't mind the inability to move forward on the TCL and Tk implementations.
>
> 2) This NT port does not run on Windows XP and some guy out there is trying
> to do a better native port, but it's really hard -- his words.
>
It is better for you to present simple Expect scripts that can not run on XP.
I tested on XP and it passed my scripts. Something wrong may be not in expect.
> 3) There is a version of Expect in the Cygwin distribution, which apparently
> does run on XP, but has some problems.
>
> My own experience is that the version of Expect in the Cygwin distribution
> immediately fries on even the simplest puts because it can't find the stdout
> channel, whatever that means (I'm just trying to find a version to work with
> on Windows XP and have no prior experience with the package.)
>
no experience on Cygwin version.
> So ... is there a definitive answer out there? Is there a modern version of
> Expect that I can use on Windows XP? Does the Cygwin version work reasonably
> well? I'd really like to use it to animate out products over telnet.
>
> Note: I work with people who tell me that Expect is torture to use and that
> I should use Perl or Java. I would like the opportunity to judge for myself,
> but so far things don't appear to be very pretty in the TCL / Expect world
> on Windows XP.
If use Perl and Java can solve your problem I suggest you use them.
Expect is for people who are well known on Unix principle.
I think Perl and Java are used to solve different problem than Expect.
I personally feel uncomfortable to use Java's messy I/O and streaming
processing. Compare to pipe and redirection in Unix they are garbage.
Chang
>
> Thanks.
David Gravereaux
>I've seen a couple of articles on this group regarding Windows XP. They seem
>to imply something like this:
>
>1) There was an excellent, but completely non-upward-compatible port of
>Expect to Windows NT 4 way back when. It runs great on Windows NT if you
>don't mind the inability to move forward on the TCL and Tk implementations.
Agreed. That is Gordon Chaffee's port. It used a special core with
patches to the pipe channel driver to support overlapped-I/O used by
namedpipes for the IPC connection to the slave driver. It does get the
job done. I do feel it has some issues in the general structure of how it
all fits together. It's quite complicated on the innards -- a bit too
complicated and I don't feel it needs such complexity.
>2) This NT port does not run on Windows XP and some guy out there is trying
>to do a better native port, but it's really hard -- his words.
Time is the issue. It needs development time and lots of it. A ground-up
redesign is what's needed. I did get the difficult part working on Win98
for trapping console API calls in the built-in debugger. What was next,
where I had left off, was to prove the "injector" can be inserted into the
debugged process's memory space, then we would be home free and it can get
a Write() method without having to jump processes and use an intermediary
to communicate console event to and from (that's the overly complicated
part in expectNT). I know that sounded terse, but it's complicated to
explain. I know I can get a useful [interact], just given the time needed
to do it (if my injector theory works, though), but that earlier project
ended and now it sits cold with no motion. Kim, get on Jeff Hobbs'
mailing list regarding Expect-win32. He was taking names a ways back.
>3) There is a version of Expect in the Cygwin distribution, which apparently
>does run on XP, but has some problems.
I personally never considered that a viable solution as it isn't native
and drags around cygwin1.dll along with it's licensing issues.
Essentailly, there are 2 camps of thought -- use the unix source as is and
make windows work like unix or take the inability of the OS to have
already provided the feature we want and work around it in a native way.
I personally like the latter as all bugs are my own.
SUMMARY: contact Jeff and work-out a contract to have Expect work on
windows.
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway,alpha sector]
Please be aware of the 7.5 year ping times when placing a call from alpha centari
Kim Letkeman
news:3D074A8E...@earthlink.net...
> Kim Letkeman wrote:
> > 3) There is a version of Expect in the Cygwin distribution, which
apparently
> > does run on XP, but has some problems.
> Best to stay away unless you're a unix architecture wizard and wish to
> pioneer.
I don't quite understand why I need to be a UNIX architecture wizard to use
a Cygwin-based application?
Kim Letkeman
news:1488E6869CD22D01.CACD9DA6...@lp.airnews.net...
> In article <HgHN8.299528$t8_.1...@news01.bloor.is.net.cable.rogers.com>,
> So: what do you *really* want?
I was dead clear on that -- a modern version of Expect on Windows XP. I have
the Cygwin version running now (although I have not pushed it to see how
much it can do), so thanks anyway ....
Kim Letkeman
> :1) There was an excellent, but completely non-upward-compatible port of
> :Expect to Windows NT 4 way back when. It runs great on Windows NT if you
> :don't mind the inability to move forward on the TCL and Tk
implementations.
>
> I am not certain what 'non-upward-compatible' means in your mind. Surely
> I would have probably have called it an 'unsupported port' of Expect.
If picking nits is your thing, then perhaps you should think about the
meaning of non-upward-compatible. Basically, it means that this port is not
compatible with future versions of TCL and Tk, which is accurate according
to virtually everything I've read about it.
I also appears to be unsupported, but that has nothing to do with the
original article, since I was asking for a modern version of Expect, not
something obsolete.
> :My own experience is that the version of Expect in the Cygwin
distribution
> :immediately fries on even the simplest puts because it can't find the
stdout
> :channel, whatever that means (I'm just trying to find a version to work
with
> :on Windows XP and have no prior experience with the package.)
>
> Perhaps if someone documents those problems and reports them, the problems
> could be fixed?
I still have not found any useful documentation on the Cygwin version of
Expect, but I did manage to find a reference to the need to define an
environment var named CYGWIN with a value of "tty" to get this problem to go
away. And it did.
> A "stdout channel" is an open file associated with a program so that the
> program can produce output.
Yes, I didn't think something so obvious needed saying, but thanks anyway.
When I said "whatever that means" I meant "why does it need to find stdout,
when it is almost always opened by default?" Sorry for the confusion.
> :So ... is there a definitive answer out there? Is there a modern version
of
> :Expect that I can use on Windows XP?
>
> I am not aware of a version that you can use.
Cygwin appears to work now, but I'll know more as I push it a little harder.
I have Don Libes' book for that.
> However, I also find Windows to be a torture to use, so I don't do it
often.
It shows.
Kim Letkeman
news:d5224ea3.02061...@posting.google.com...
> It is better for you to present simple Expect scripts that can not run on
XP.
> I tested on XP and it passed my scripts. Something wrong may be not in
expect.
I was quoting what I read. Frankly, I'd prefer not to install and test an
obsolete package, which is why I asked if anyone knew of something more
modern. I now have the latest Cygwin version running, so we'll see how it
goes.
> > So ... is there a definitive answer out there? Is there a modern version
of
> > Expect that I can use on Windows XP? Does the Cygwin version work
reasonably
> > well? I'd really like to use it to animate out products over telnet.
> >
> > Note: I work with people who tell me that Expect is torture to use and
that
> > I should use Perl or Java. I would like the opportunity to judge for
myself,
> > but so far things don't appear to be very pretty in the TCL / Expect
world
> > on Windows XP.
>
> If use Perl and Java can solve your problem I suggest you use them.
If you remember, I was asking for a modern version of Expect to run on
Windows XP, not a solution to any particular problem.
> Expect is for people who are well known on Unix principle.
I disagree with this statement. Expect, as far as I can tell, is for people
who want the simplest and most robust mechanism for automating other
programs. Unix principles such as i/o redirection and such play a part in
that, but Expect takes care of that for me. I'm not interested in playing
with the source, I want to use the application.
> I think Perl and Java are used to solve different problem than Expect.
> I personally feel uncomfortable to use Java's messy I/O and streaming
> processing. Compare to pipe and redirection in Unix they are garbage.
Java and Perl use more lines than Expect to do the same thing. But make no
mistake, they can do the same things as Expect and TCL. I don't think that
they are garbage, just not appropriate as tools for this purpose when a
better solution (Expect) is readily available.
Kim Letkeman
news:4g8fgu8e456od4vgn...@4ax.com...
> "Kim Letkeman" <kim.le...@rogers.com> wrote:
> >3) There is a version of Expect in the Cygwin distribution, which
apparently
> >does run on XP, but has some problems.
>
> I personally never considered that a viable solution as it isn't native
> and drags around cygwin1.dll along with it's licensing issues.
I'm not sure why dragging Cygwin around is a problem. I have been using
Cygwin for years, and my favorite tools from my Unix years seem to work
flawlessly. I just didn't know how to get that version of Expect to work
when I wrote the original request for help. I do now, the incantation being
to define a var CYGWIN with value "tty". That's a pretty goofy requirement,
but ultimately harmless enough.
> Essentailly, there are 2 camps of thought -- use the unix source as is and
> make windows work like unix or take the inability of the OS to have
> already provided the feature we want and work around it in a native way.
> I personally like the latter as all bugs are my own.
Anything that makes support easier (as in requires less forking of the code)
is a huge plus, especially in the resource-limited world of open source. I
have to disagree with you on your premise that native is better. In fact,
Cygwin is the moral equivalent of the adapter pattern from one very
different OS family to Unix, and as such is a brilliant solution to getting
access to those tools and the scarce resources that maintain them.
IMO of course.
Roy Terry
over any hurdles in this regard (and maybe a wizard in the sense
I was going for). And if it works for you great.
My individual assessement of Cygwin was not positive and I haven't
wanted to go back as I felt the faking of one OS on top of another
was basically unappealing. Again YMMV. Seems to me like you are
making your own "definitive" - so much the better.
Cheers,
Roy
David Gravereaux
>"David Gravereaux" <davy...@pobox.com> wrote in message
>news:4g8fgu8e456od4vgn...@4ax.com...
>> "Kim Letkeman" <kim.le...@rogers.com> wrote:
>> >3) There is a version of Expect in the Cygwin distribution, which
>apparently
>> >does run on XP, but has some problems.
>>
>> I personally never considered that a viable solution as it isn't native
>> and drags around cygwin1.dll along with it's licensing issues.
>
>I'm not sure why dragging Cygwin around is a problem.
Let's say you are in the business of telcom switches and you need to make
your software product work on windows (marketing push) and you use Expect
for driving the automation of telnet over ATM or whatever it is. All
things work great on Solaris, Linux, etc. But how can you use the
cygwin1.dll in a product you sell? Aren't the restrictions on it rather
tight?
How could you make it all one big static shell with TclPro's wrapper or
FreeWrap? A native extension isn't a problem that limits external
dependencies. There's a few issues with Expect like the Stubs problem and
small issues around over naming of [close] and [continue].
> I have been using
>Cygwin for years, and my favorite tools from my Unix years seem to work
>flawlessly. I just didn't know how to get that version of Expect to work
>when I wrote the original request for help. I do now, the incantation being
>to define a var CYGWIN with value "tty". That's a pretty goofy requirement,
>but ultimately harmless enough.
>
>> Essentailly, there are 2 camps of thought -- use the unix source as is and
>> make windows work like unix or take the inability of the OS to have
>> already provided the feature we want and work around it in a native way.
>> I personally like the latter as all bugs are my own.
>
>Anything that makes support easier (as in requires less forking of the code)
>is a huge plus, especially in the resource-limited world of open source.
There is no fork. The code I have is on a branch in the main Expect
repository on sourceforge with the goal to eventually merge it up to the
head. It is platform split in the same way the Tcl source is, but not
forked. I do wonder if the cygwin source distribution is different than
the code housed in the SF repository for Expect.
> I
>have to disagree with you on your premise that native is better. In fact,
>Cygwin is the moral equivalent of the adapter pattern from one very
>different OS family to Unix, and as such is a brilliant solution to getting
>access to those tools and the scarce resources that maintain them.
>
>IMO of course.
>
Of course.
I had a problem while doing part of the port work where I wasn't able to
set external process memory under win98. All I did to fix it was read up
on CreateFileMapping() and how to make it act like VirtualAllocEx() under
NT. My bug -- no one elses. I remember some issue with cygwin in the
emulation of fork() under win98 some time ago.
Tcl is also a moral equivalent of an adapter pattern as well.
Chang Li
> "Chang Li" <CHA...@neatware.com> wrote in message
> news:d5224ea3.02061...@posting.google.com...
> > It is better for you to present simple Expect scripts that can not run on
> XP. I tested on XP and it passed my scripts. Something wrong may be not in
> expect.
>
> I was quoting what I read. Frankly, I'd prefer not to install and test an
> obsolete package, which is why I asked if anyone knew of something more
> modern. I now have the latest Cygwin version running, so we'll see how it
> goes.
The problem of Expect on NT is only worked for Tcl 8.0.
I remembered that Telnet bundled in XP may cause some troubles.
When you replaced it no problem anymore.
XP is acturally based on Windows2000 kernel rather than NT.
There are minor differences but may cause big result.
Some old C program may work on NT but may crash on Windows2000
because win2000 raise the exception when there is an error
of memory access. NT may ignore this. Win2000/XP caught the
bug but NT ignore it.
>
> > > So ... is there a definitive answer out there? Is there a modern version
> of
> > > Expect that I can use on Windows XP? Does the Cygwin version work
> reasonably
> > > well? I'd really like to use it to animate out products over telnet.
> > >
> > > Note: I work with people who tell me that Expect is torture to use and
> that
> > > I should use Perl or Java. I would like the opportunity to judge for
> myself,
> > > but so far things don't appear to be very pretty in the TCL / Expect
> world
> > > on Windows XP.
> >
> > If use Perl and Java can solve your problem I suggest you use them.
>
> If you remember, I was asking for a modern version of Expect to run on
> Windows XP, not a solution to any particular problem.
It all dependents on the Cygwin implementation on Windows.
If Cygwin implements a true Unix system under Windows with its DLLs
Expect will be fine. But if Cygwin really work why users need VMWare?
>
> > Expect is for people who are well known on Unix principle.
>
> I disagree with this statement. Expect, as far as I can tell, is for people
> who want the simplest and most robust mechanism for automating other
> programs. Unix principles such as i/o redirection and such play a part in
> that, but Expect takes care of that for me. I'm not interested in playing
> with the source, I want to use the application.
>
Expect worked on the high level. However, Expect is worked in the Unix
way
in advanced. If a user has no idea about the shell and telnet, he may
feel
pain to use it. This is especially true for Windows developers. There
are
many developers study Java and VB at first. They may not know command
line, shell, and telnet. Windows software hide their complex in the
GUI, but if
you want do real programming, it is much more difficult than Unix in
many
aspects especially in naming pipe and console.
> > I think Perl and Java are used to solve different problem than Expect.
> > I personally feel uncomfortable to use Java's messy I/O and streaming
> > processing. Compare to pipe and redirection in Unix they are garbage.
>
> Java and Perl use more lines than Expect to do the same thing. But make no
> mistake, they can do the same things as Expect and TCL. I don't think that
> they are garbage, just not appropriate as tools for this purpose when a
> better solution (Expect) is readily available.
If Expect code can be easily done by Java or Perl, Expect would have
been ported to these languages. Think about it why there is no
Java/Expect?
Chang
David Gravereaux
>> I personally never considered that a viable solution as it isn't native
>> and drags around cygwin1.dll along with it's licensing issues.
>
>I'm not sure why dragging Cygwin around is a problem. I have been using
>Cygwin for years, and my favorite tools from my Unix years seem to work
>flawlessly. I just didn't know how to get that version of Expect to work
>when I wrote the original request for help. I do now, the incantation being
>to define a var CYGWIN with value "tty". That's a pretty goofy requirement,
>but ultimately harmless enough.
I was just experimenting with cygwin's expect and found a nice flaw. Say
you have a true Win32 console application like, for this example,
Borland's Turbo Debugger v5.5 that comes with their free commandline
tools.
It's pure console in that it runs a true character-mode UI -- not GUI, nor
stdio. Rather rare these days, but they exist. Spawning it from expect
with log_user = 0 doesn't place it in the background. It takes over the
whole console window instead. Spawning the cygwin tools like shh, etc.
work well, though. More than likely from the internal hooks added to
support it.
IMO, a windows port of expect should include the ability to use windows
console programs.
David Gravereaux
>It's pure console in that it runs a true character-mode UI -- not GUI, nor
>stdio. Rather rare these days, but they exist.
Speaking of telcom, I remember this cell phone programmer/downloader I had
to use when I was working for Sprint in hawai`i. I forget the brand; it
wasn't qualcomm or sony. The app was pure win32 console and a real
expect-win32 could have been helpful, although I wasn't employed to
automate the reflashing, just reflash.
Kim Letkeman
news:d5224ea3.02061...@posting.google.com...
> "Kim Letkeman" <kim.le...@rogers.com> wrote in message
news:<KiIO8.27051$831....@news01.bloor.is.net.cable.rogers.com>...
> > Windows XP, not a solution to any particular problem.
>
> It all dependents on the Cygwin implementation on Windows.
> If Cygwin implements a true Unix system under Windows with its DLLs
> Expect will be fine. But if Cygwin really work why users need VMWare?
With VM-Ware, you can run multiple versions of Windows on your machine --
Win98 for really old games that you like, and Win2k or WinXP for your
day-to-day productivity applications. You can add Linux on another partition
for hacking with your favorite unix apps. And they all run nicely together.
There are also situations where you want to run disparate servers together
to create a larger app, for example a server that you write in .NET must
communicate with a server written for Linux (for example the Speechworks TTS
engines.) This might require multiple physical servers. If you can stay
small though, you can get away with one big machine, running multiple
virtual servers on a big machine.
My point being that these are very different problems than that of running a
bunch of unix tools under Windows using Cygwin.
> If Expect code can be easily done by Java or Perl, Expect would have
> been ported to these languages. Think about it why there is no
> Java/Expect?
My guess is that the Expect 'C' library could easily be used under Java. I
would even hazard a guess that someone out there is using it in this way (to
integrate automation into an existing Java-based test suite.) It is not
necessary in my opinion for someone out there to release an official Java
package for Expect, because there is already a C library for it. But it
might be nice for someone to wrap it all up in a nice class.
Kim Letkeman
> "Kim Letkeman" <kim.le...@rogers.com> wrote:
>
> Let's say you are in the business of telcom switches and you need to make
> your software product work on windows (marketing push) and you use Expect
> for driving the automation of telnet over ATM or whatever it is. All
> things work great on Solaris, Linux, etc. But how can you use the
> cygwin1.dll in a product you sell? Aren't the restrictions on it rather
> tight?
I have not read all the licensing thoroughly. I know that some open source
stuff gets sold in products (TCL built into Wind River products for
example). I don't know if Cygwin DLL is more restrictive than other GPL
stuff. But I know that I'm talking about using this stuff for personal use,
and at most for a few shared tools. This gets nowhere near our product, for
obvious reasons. I'm used to seeing inferior tools used in products because
of the risk of adopting anything with GPL on it, so this is no big deal to
me.
> There is no fork. The code I have is on a branch in the main Expect
> repository on sourceforge with the goal to eventually merge it up to the
> head. It is platform split in the same way the Tcl source is, but not
> forked. I do wonder if the cygwin source distribution is different than
> the code housed in the SF repository for Expect.
I don't know how the "platform split" works, but for the duration of your
port, the source base is split, at least the portion that must be native.
This is what I meant by fork (as opposed to whatever formal definition might
exist in the open source world.) If the same thing could be accomplished
with a few very simple extensions and then run on Cygwin, we have what we
need with virtually no effort. That was my point, and I think it's still
valid.
Kim Letkeman
> "Kim Letkeman" <kim.le...@rogers.com> wrote:
> >I'm not sure why dragging Cygwin around is a problem. I have been using
> >Cygwin for years, and my favorite tools from my Unix years seem to work
> >flawlessly. I just didn't know how to get that version of Expect to work
> >when I wrote the original request for help. I do now, the incantation
being
> >to define a var CYGWIN with value "tty". That's a pretty goofy
requirement,
> >but ultimately harmless enough.
>
> I was just experimenting with cygwin's expect and found a nice flaw. Say
> you have a true Win32 console application like, for this example,
> Borland's Turbo Debugger v5.5 that comes with their free commandline
> tools.
>
> It's pure console in that it runs a true character-mode UI -- not GUI, nor
> stdio. Rather rare these days, but they exist. Spawning it from expect
> with log_user = 0 doesn't place it in the background. It takes over the
> whole console window instead. Spawning the cygwin tools like shh, etc.
> work well, though. More than likely from the internal hooks added to
> support it.
Then one should probably spawn a wrapper app (using the Windows hook
facility) that provides a new (invisible) window for the old-style console
app to take over. The wrapper would adapt the console i/o to stdin and
stdout. Doesn't sound all that ugly to me.
> IMO, a windows port of expect should include the ability to use windows
> console programs.
Any app that runs *as* a Windows console (which is not the same as running
*in* a console using stdin and stdout) will not play nice in the unix
environment. But that should be viewed as a flaw in the app, not the Cygwin
port of Expect.
Generalized adapting of older-style console apps is effectively the same job
as adapting Windows GUI apps. Someone has to do it, but only if it is useful
enough to warrant the effort.
David Gravereaux
>Then one should probably spawn a wrapper app (using the Windows hook
>facility) that provides a new (invisible) window for the old-style console
>app to take over. The wrapper would adapt the console i/o to stdin and
>stdout. Doesn't sound all that ugly to me.
See the code in the Expect repository for the exact design of what you describe. Or
just download it @ http://prdownloads.sourceforge.net/expect/slavedrv1.0.zip
The slavedrv app was rewritten to be a test container of a new design to do exactly
that. But without the spawn aspect and eliminates the man-in-the-middle process by
doing it directly. The Write() function is missing, though. I have a theory on how
to place an "injector" into the slave-side, but it's untested.
Windows hooking only works with window menus as I recall. Gordon's port used a
debugger for running the slave within to trap all calls to the console APIs and
transfer the info over. I rewrote it a bit and changed some aspects of the model
and maybe with some assistance, I'll get [interact] happening. I somewhat doubt any
useful info could be obtained by subclassing the console window itself.
>> IMO, a windows port of expect should include the ability to use windows
>> console programs.
>
>Any app that runs *as* a Windows console (which is not the same as running
>*in* a console using stdin and stdout) will not play nice in the unix
>environment. But that should be viewed as a flaw in the app, not the Cygwin
>port of Expect.
Sorry. That description doesn't hold water. A win32 console program is not a
console unto itself, but runs within one taking over the parent's, or not, depending
on the use of the Win32 API. When the OS starts a console process, the console
subsystem will allocate a new one if launched detached. You can also be explicit
and ask the subsystem not to make a new one. [exec] under wish does this. Win2K's
telnet.exe (console/TUI) blows up really hard if you do that, not surprisingly. See
attachment.
On unix, Expect can work with telnet and it isn't stdio (CLI). termcap is involved
with cursor movement, color and all that fun stuff that Expect was designed to
handle gracefully. a/k/a TUI. The job Expect should do on window shouldn't be any
different. The implementation, yes, but not the goal.
>Generalized adapting of older-style console apps is effectively the same job
>as adapting Windows GUI apps. Someone has to do it, but only if it is useful
>enough to warrant the effort.
How so? How does GUI relate to TUI in relation to Expect? Are you bringing up the
idea of interacting with GUI apps. There's an X event recorder I was reading about
some time ago. I think it's mostly used for testing/verification or macro style
playback, but I forget the name off hand. I don't think the Expect project should
attempt such a feat.
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway,alpha sector]
Please be aware of the 8.7 year ping times when placing a call from alpha centauri
http://home.sunrise.ch/schatzer/Alpha-Centauri.html
Frank Pilhofer
>
> But how can you use the
> cygwin1.dll in a product you sell? Aren't the restrictions on it rather
> tight?
>
The Cygwin library is covered by the GPL. So all programs that use it,
and are being redistributed in binary, must be covered by the GPL as
well.
There's two possibilities - one is that you can redistribute your source,
so that customers can make download cygwin and do the compiling. The other
is to buy Cygwin from redhat: http://www.redhat.com/software/tools/cygwin/
Frank
--
Frank Pilhofer ........................................... f...@fpx.de
Ever notice that to entertain some people all you have to do is
listen? - Alfred E. Neuman
David Gravereaux
>See the code in the Expect repository for the exact design of what you describe. Or
>just download it @ http://prdownloads.sourceforge.net/expect/slavedrv1.0.zip
C:\> slavedrv.exe stdio dbg <consoleApp> [args..]
Please excuse the VT100 codes. I left them in, but plan to yank them, as they
aren't needed.
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
D:\expect_wslive\expect_win32_take2\win\Release>prompt=$g
>slavedrv.exe stdio dbg c:\dev\bcc55\bin\td32.exe
Turbo Debugger 32-bit Version 5.5 Copyright (c) 1988, 2000 Inprise Corporation
?[1;1H?[1;1H = File Edit View Run Breakpoints Data Options Window Help
ŚŚŚŚŚŚŚŚŚŚŚ?[2;1HŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ
ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ?[3;1HŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ
ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ?[4;1HŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ
ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ?[5;1HŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ
ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ?[6;1HŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ
ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ?[7;1HŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ
ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ?[8;1HŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ
ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ?[9;1HŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ
....etc...
David Gravereaux
>David Gravereaux <davy...@pobox.com> wrote:
>>
>> But how can you use the
>> cygwin1.dll in a product you sell? Aren't the restrictions on it rather
>> tight?
>>
>
> The Cygwin library is covered by the GPL. So all programs that use it,
>and are being redistributed in binary, must be covered by the GPL as
>well.
>
> There's two possibilities - one is that you can redistribute your source,
>so that customers can make download cygwin and do the compiling. The other
>is to buy Cygwin from redhat: http://www.redhat.com/software/tools/cygwin/
>
> Frank
Tcl itself is under BSD and Expect is a form of public-domain, I think.
That's a whole lot freer than GPL with it's viral aspect.
--
David Gravereaux <davy...@pobox.com>
[species: human; planet: earth,milkyway,alpha sector]
Please be aware of the 8.7 year ping times when placing a call from alpha centauri
http://home.sunrise.ch/schatzer/Alpha-Centauri.html
Kim Letkeman
> Tcl itself is under BSD and Expect is a form of public-domain, I think.
> That's a whole lot freer than GPL with it's viral aspect.
Well, that's good news anyway. GPL has kept more good open source software
from being widely used and adopted than any other single factor .... in my
opinion of course.
Mo
> > That's a whole lot freer than GPL with it's viral aspect.
>
> Well, that's good news anyway. GPL has kept more good open source software
> from being widely used and adopted than any other single factor .... in my
> opinion of course.
I don't know about that guys. GCC and GDB are GPLed and they are certainly
more widely used than Tcl. As far as the Cygwin goes, you can always buy
a license from Red Hat if you don't want to release integrated code. There
is also an exception in the Cygwin license for code that meets the OSD.
That is why projects like Jikes can provide a Cygwin version without having
to GPL the source code.
I think the Cygwin dual license approach is an interesting one. It lets
most everyone use the code and still provides a means to extract $$
from businesses that make use of Cygwin. We all know that people
are lazy and cheap. If folks could just swipe the code no questions
asked, they would. If Cygwin were under a BSD license it would have
been stolen by Microsoft long ago (see Interix).
Mo
Kim Letkeman
> We all know that people are lazy and cheap. If folks could just swipe the
> code no questions asked, they would.
People are neither lazy nor cheap. Everyone wants working code to start
from, especially for pieces of a system that are outside the core expertise
of those available to do a project. They'll take it where they can get it,
and most are happy to pay for good code, assuming that the seller isn't
greedy in the extreme (like asking for a percentage of every sale of the
derivative product .... sheesh.)
> If Cygwin were under a BSD license it would have been stolen by
> Microsoft long ago (see Interix).
Right, Microsoft is sitting in awe of Red Hat. They can't wait to snarf all
that great code and parlay their measly 21B (9 months to 31 Mar 2002) into
119M (12 months to 28 Feb 2002).
In my opinion, "open source" is a misleading term. It is open to people in
the "open source" community, and not very open to anyone else. The GPL
precludes the use of "open source" except as a part of more "open source". I
suppose there's a certain symmetry in that :-).