Wow, a blast from the past. I still have some expect tools I wrote long ago that I use and maintain to this day. Not so much new stuff since scripting languages have gotten better at doing what expect does -- often calling their modules "expect" and using the exact same syntax.
I once wrote a webserver in Expect. No, it's not a good language for writing a webserver.
Tcl is a perfectly fine language for writing web servers with, actually. It was possible to do a nice, lightweight, evented web server years before Node.js showed up. AOLserver is also done with Tcl, and for a while in the 90ies, was one of the best systems for doing dynamic web sites.
When you say it was one of the best systems for doing dynamic websites, would you use it on its own, or was it more popular to use OpenACS on top of it? (Which is what one of the codebases I still work on today does)
My understanding was that AOLserver was the NCSA (pre-Apache httpd) server, with TCL as an extension language, not that AOLserver was written in TCL. Weird.
Pairing with C is the whole point of Tcl; in its heyday, Tcl was known for having one of the easiest extension APIs of all the scripting languages. The idea of using a scripting language to knit C code together was one of Ousterhout's key goals.
Also: no other scripting language with the possible exception of JS has evented I/O so fundamentally baked into the core of the language.
Tcl shows up in all sorts of places, like Cisco IOS, or haptic feedback robotic surgery interfaces, or IRC bots. It's fast, it's small, it's robust, it's powerful. It's just not sexy.
Be sure to check out "autoexpect": it starts an interactive session, and generates an expect script based on that. Then you typically need to edit it for generalization (e.g., skip dates and time strings; often skip version strings, etc.).
How did I not know about this? Autoexpect is one of the thousand ways of interacting with computers that we USED to do back in the 80s and 90s that have since fallen out of favor. Macros, modem dialers, folder watchers, etc.. Remember trying the record button in Applecript Editor, only to find that it didn't actually work like it did in Macro Maker? The fact that autoexpect isn't installed by default on Mac OS blows my mind.
Edit: still trying to install autoexpect on Mac OS 10.9.2 and having no luck. Tried ActiveTcl at http://www.activestate.com/activetcl/downloads but it doesn't seem to have autoexpect. Tried brew install autoexpect, tried port install autoexpect, nothing. Sometimes unix reminds me of looking up hints in video game magazines upon finding oneself stuck, so if someone knows how to get autoexpect on Mac, please let us know because I'm throwing in the towel.
I use it to install MySQL with some non default values. I'm not that good with bash and install scripts and expect was the only way around some issues I was having.
secure_mysql_script=$(expect -c '
spawn sudo mysql_secure_installation
expect "Enter current password for root (enter for none):"
send "\r"
expect "Change the root password?"
send "n\r"
expect "Remove anonymous users?"
send "y\r"
expect "Disallow root login remotely?"
send "y\r"
expect "Remove test database and access to it?"
send "y\r"
expect "Reload privilege tables now?"
send "y\r"
expect eof
')
echo "$secure_mysql_script"
I have a somewhat similar tool but it doesn't do much besides check for password expiry and do password changes.
It uses pexpect but also multiprocessing and multiprocessing.Queue. I built most of it before we started using Ansible at work, but it is still useful in those places where Ansible is clumsy.
I used to use expect to automate a bunch of business reports and system functions. I switched to a python work-alike called pexpect that I still use and love. It feels a little hacky but it works and saves a huge amount of time over the course of a year.
Oh expect. I've got a crappy little script I wrote when I was a sysadmin at Ticketmaster used to change a lot of our out of band management card passwords:
I first discovered this about two months ago. It may be old, but it solved a problem we had and nothing else quite fit the job. We're using it to run a flaky test suite and count how many times it succeeds, fails, or times out (yes, times out - yay Android!). Very important when you're trying to determine if potential stability improvements actually make a difference or not, and you need to run the 3 minute suite ten times at least to get something statistically significant.
Expect for Windows has been finicky for me every time I've tried using it, but Cygwin Expect works well, both for interacting with other Cygwin processes (not arbitrary Win32 console apps!), and for interacting with remote machines via (Cygwin) Telnet and SSH.
Here's a neat integration test suite written in expect for an HPC job launcher. Diving into this was my introduction to expect. It's a very practical little tool.
expect is one of the most useful system administration tools out there! I've used it to batch-modify settings on 100 machines where I couldn't just scp in a new file due to each one needing small variations.
If you don't know expect (and you're a sysadmin), learn it.
Expect is one of the few reliable ways I've found to automate crufty, closed source things. Say, like a perforce client pull that uses a caching proxy so that the proxy is up to date for actual human pulls.
We used Expect recently to automate iOS runtime hacking (ssh to jailbroken iOS device, run cycript to inject code, profit). One of those old Unix tools (built on tcl) that's very handy for automation.
It's very frustrating to see something like this that claims to be very useful, but shows no examples on the page.
>Expect is a tool for automating interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc. Expect really makes this stuff trivial.
How?
>Expect can make easy all sorts of tasks that are prohibitively difficult with anything else. You will find that Expect is an absolutely invaluable tool - using it, you will be able to automate tasks that you've never even thought of before - and you'll be able to do this automation quickly and easily.
This script runs the meteor deploy command as part of my CI loop every time new code gets pushed to github. The deploy command expects me to type in a bunch of information, and expect does that for me.
Expect is great, however if you ever determine that using it is the best way to solve your problem, then you are probably approaching the problem the wrong way in the first place (the best way to proceed from that point may very well be to continue using expect though).
I used it a few years ago to create a test suite for some dedicated VoIP hardware (controlling the boxes over telnet). It worked great, but if I had had more time, that definitely would not have been my approach.
I once wrote a webserver in Expect. No, it's not a good language for writing a webserver.