It seems like Expect is not actively developed

It is.

The title above is an exact quote from correspondence I received in the summer of 2007, and echoes what many, many others have written or said to me.

They're wrong.

Well, they're right, of course: Expect gives them the appearance of dormancy. I haven't researched what all goes into this, but I'm almost certainly there are basic errors of fact afoot.

It's certainly true that Expect, and Tcl more generally, is managed conservatively. It is maintained, though, and with considerable care and expertise. In particular, I know that it remains ahead of what the corresponding Expect extensions for Perl and Python achieve.

I think it'd be great for people to mention here the evidence they have of Expect's stagnation; perhaps we can collaborate to understand better its true state.


Amit says:

I was one of the few correspondences of the above issue. A few reasons why I mention this.

  1. At least as far as I know, there has only been one book of Expect released and that is by the original author titled "Exploring Expect." -- I have read quite a few statements saying that there is no need for another book since this book just "nails it."
  2. It is hard to find updated documentation, blogs, articles, or expect use cases. -- The most recent one I've found was surprisingly written only a couple of months back and actually inspired me to really consider Expect. [L1 ]
  3. I couldn't find a list of simple examples for expect. I was looking for something like a cookbook with a bunch small expect scripts.
  4. What about pexpect [L2 ]? Are there any advantages to it rather than using regular expect?

Don't get me wrong. I played around with expect and I love its power but I just didn't want to jump into it if there are newer and more powerful alternatives.


LV 2007 Sep 11 Perhaps the phrase "actively developed" needs to be defined.

To me, the phrase means "on a frequent basis, new features and examples are added, documentation is being updated and expanded, and bugs are fixed." What does the phrase mean to those expressing the sentiment in relationship to Expect mean?

To me, Expect is not, in fact, actively being developed. It is, however, actively being maintained. In other words, new features are not being added to Expect. New demos are not being added. New reference pages or tutorials are not being added to the source distribution.

However, care is being taken to ensure that the extension continues to work with new releases of Tcl. A visit to http://sf.net/projects/expect/ and a click on the "Browse CVS" link, shows a ChangeLog update during August 2007 and that files shows over 100 lines of change description for 2007 on a whole.

Now, if there are specific changes that you are wanting, perhaps those should be submitted. I notice there have been no patches added to the patch tracker since 2004. There have only been 4 feature requests ever submitted, and the one that is still open is a request to put the expect docs up at sf.net - no new features listed there. In fact, I see less than a dozen bugs reported during 2007. I have no idea whether these are resolved in the current version or not.

So, either people are not using Expect, it is doing what they need it to do, or they are not discussing the missing functionality.

Given that there is no great demand for new features, it shouldn't be a surprise that there are no active developers. Perhaps, when new feature needs arise, new developers will step up.


Tykling 22nd Nov 2007

I think people are just having a hard time accepting that Expect in its current form is complete. Does what it is supposed to. No need for a new version.

Nowadays I think people expect everything to keep getting new features; lots of open source projects are under constant development (even though new features perhaps aren't necessary).

LV I understand what you mean. However, many tcl extensions take the approach of resisting creeping featurism. In other words, don't make changes just to churn the waters... instead, only change things that are broken, or add things that are, in fact, needed but not easily done with existing tools.