Aw man I love Expect. We have a bunch of legacy stuff and Tcl/Expect powers most of it. Every few years people try to replace it with python and pexpect, there was a nodejs implementation, and perl. They sorta worked, but anytime you had to something more complicated than a single session or simple parsing they fell apart.
now I have it wrapped in a starpack and just dont tell them the language unless they ask lol
Expect has had remarkable longevity, though I'd say the greatest impact of Tcl has been though *sqlite* which started as a Tcl extension and still uses Tcl in its development. Sqlite is used so very widely, hard to find any major software that doesn't incorporate it. I guess Tcl is nearly everywhere, under the hood anyway.
Re:The Birth of Tcl
by AceJohnny2 on Thursday April 21, 2022 @03:58PM
(#31114476)
Furthermore, I've been wanting to give our embedded app's CLI some smarts, add some control-flow features, and I can think of no better way to do implement that than make it a TCL shell.
I think expect is a result of having no programatic interface for command line tools. I ofter wonder how much more useful these command line tools, and how many hundreds of man years would have been saved with buggy text parsers, if there was a programatic stdin/stdout, in addition to the one for humans, from the beginning.
But, with the reality we live in, expect helped me many times in the past. These days, I use python's pexpect for the same use cases.
Expect remains an essential tool for dealing with interactive (but not TUI) terminal application, and in usage really fits its TCL roots perfectly. In contrast, I've found the Perl and Python ports of Expect to be somewhat awkward, not fitting those languages paradigms as well.
In the 2020s, I still think Expect is TCL's killer app.