Expect – automates programs that expose a text terminal interface
en.wikipedia.org
en.wikipedia.org
Expect made it really easy to automate this sort of testing - where the only way you can configure something is via the CLI and you want to be able to do this even when the only connection is via a serial console (for router reboots). We used to run it daily and as an engineer just out of school it was an eye-opening experience: because of the daily runs you got to see just how often people's commits could break simple functionality in other parts of the system.
A while back I wrote a short blog post on it with a more advanced example on a debugging workflow with Rails: http://www.chocobrain.com/Terminal-Automation-expect-Advance...
(ssh into production -> open rails-console -> type out initial commands -> let user enter commands)
Even so, if you've got to get the job done and can worry about architectural issues at a later time, expect is great.
I'm sufficiently involved with Expect that I've collected enough material for an entire book on the subject (serious--I do a lot of writing, and am well aware of what's involved in such a publication); at the same time, I know that jlgreco is EXACTLY right that Expect use is a symptom of a larger problem. Much of what I've already published through the years about Expect is how a particular task that used to be done with Expect now can better be handled with automation-interface-X.
[http://sage.math.washington.edu/home/goreckc/sage/wexpect/]
Back then I even released an open-source utility written in Expect, that connects and controls multiple hosts. It is essentially a shell that sends each command to all connected hosts and collects the responses. It even supports automatic translation of commands to supports different shells on different hosts. It's taken me a while to find it (I even forgot what I named it), but now I remember: http://sourceforge.net/projects/sysman/. It even had some pretty nifty features, apparantly: http://sysman.sourceforge.net/
Thanks for the reminder!
Also, Tcl turned out to be pretty sweet.
I used expect back in the day for a number of purposes.
This is much more secure, in my opinion, than using a webhook to deploy new commits.
You may have to tweak it a bit to get it working with your specific ssh agent forwarding and ssh keys by only by deleting a few lines, but it works out of the box without those features.
There's also a nice script called autoexpect that writes simple expect scripts based on your input: Just execute autoexpect, it will spawn a shell and write a file "script.exp" based on what your type and the responses your get.
That said, just like with Web scraping, when you need it, nothing else will do. It's an invaluable tool for that reason, especially when you have to work with code you don't control.
One of the difficulties with Expect is that it's hard to explain its usefulness to newcomers. Expect itself is easy enough to understand; but a common initial reaction is, "So?"
Part of the difficulty is that Expect particularly shines in occasional circumstances that no one wants to repeat. It's a tool, more than a product--like a funny little jig that looks peculiar, but saves HOURS when you are doing particular operations with a drill press.
Network devops, for instance, might need to monitor and update hundreds of devices spread across multiple datacenters for a particular task accessed through a command-line interface (CLI). The CLI is "easy", in that it only takes thirty seconds to do one instance of the chore--but a royal nuisance to repeat for hour after hour. A "correct" answer probably involves setting up authentication key pairs and ... well, you can see where this is going. How "correct" is that kind of configuration, though, when it might have to be done only once in the lifetime of the datacenters? This is a typical case where twenty minutes of Expect scripting can save HOURS, and sometimes days, of error-prone typing. It would easily be worth hundreds of dollars to have Expect on hand for this one use. No one will ever pay for Expect, though, because it helps most for these pesky side-tasks that no one really budgets.
I can give lots of examples of good uses for Expect--but each single example will only apply to a handful of people around the world. Nearly everyone needs Expect in some way, but each instance is highly idiosyncratic.
Expect is a little like duct tape or WD-40.