Expect – Writing a Tcl Extension in Only Seven Years (1997)(nist.gov)
nist.gov
Expect – Writing a Tcl Extension in Only Seven Years (1997)
http://www.nist.gov/customcf/get_pdf.cfm?pub_id=821282
9 comments
What's next for Tcl? I'm a fan.
There's the Caius framework:
http://caiusproject.com/
I haven't spent any hands-on time with it yet, but what I've read so far is what led me to start learning more about expect, and Tcl in general. I'm looking for a robust way to test the systems I'm building with docker: machine, compose (fig), swarm, etc.
http://caiusproject.com/
I haven't spent any hands-on time with it yet, but what I've read so far is what led me to start learning more about expect, and Tcl in general. I'm looking for a robust way to test the systems I'm building with docker: machine, compose (fig), swarm, etc.
Neat. I wrote TCL like 10 years ago daily, mostly for different shell scripts and Eggdrop extensions. That was fun…
is expect still the default tool for command line automation, or has it been superseded by something else?
I haven't seen anything else in use anywhere. I believe it's still pretty much the undisputed king.
Perl has the work-alike Expect module.
Python has one as well: https://pexpect.readthedocs.org/en/latest/
…and Ruby has the PTY module which includes an `expect` method, which is in the same ballpark:
http://ruby-doc.org/stdlib-2.2.0/libdoc/pty/rdoc/PTY.html
http://ruby-doc.org/stdlib-2.2.0/libdoc/pty/rdoc/PTY.html
I have found that simply opening sockets , pipes or serial ports and "fconfigure -translation binary -blocking 0 -buffering none" and using event driven I/O in regular Tcl to be superior. You use this same pattern for all activity, which makes things more consistent.