Hacker News Reader

Comment by pram | Hacker News Reader

I used expect a ton a decade+ ago to script a bunch of ncurses-esque menus over a telnet connection. It was an obscure tool even then.

I can’t think of much I’d use it for today. Ansible is far better.

It was mostly helpful when you had to deal with a mainframe terminal program that was otherwise impossible to automate.

View on HN

Also surprised to see this at HN. The approach to automating interactive applications based on pty superpose (and I/O direction) coupled to a pattern->action model is an extremely old fashioned approach. 20 years ago expect was an invaluable tool though. The model for developing cli tools has changed so much in reaction that very few use cases for 'vanilla' expect remain. Not to mention that TCL is not a very popular PL and unlikely to make a comeback.

'expect' is definitely for edge-case automation, but in the few cases where it is useful, it is extremely useful. Despite the fact that it's quite 'old fashioned', it is a dependency of DejaGnu which, itself, is a dependency of the test cases for a huge number of GNU projects. This leads me to believe that it'll still be around for a very long time and will continue to work the same as it does now.

I used it as recently as a couple years ago to make short work of some build + deployment stuff on some slightly unusual platform. Might've been Garmin wearables? Something like that.

When you need "expect", it's wonderful.

Sure, but is it worth learning TCL for a few edge-cases? I like python, so I used "pexpect" in the past. I am sure other languages have such libraries too.

And if you are going for solid production, you probably want to re-implement "expect" anyway -- so all input is whitelisted and unexpected messages are flagged. You probably don't what to break your expensive 1990's industrial device because you were driving it with expect script, and it cheerfully ignored "WARNING RESERVE BATTERY DEAD, REPLACE BEFORE POWER OFF" messages.

If all software was designed for scale, there would be no use for expect. It's 2019 and I still have expect in production:

  * to deploy commercial software whose configuration is only through  an interactive terminal session and stored in an undocumented binary format
  * to drive gdb to inspect a suspect Red Hat 6 "will not fix" GUI component that can go into an "impossible" pure cpu loop, to determine whether to kill it or whether it's busy in a more benign state.

Edit: the deploy is invoked by ansible, whose own expect module recommends the real expect "for complex cases"

fish shell uses expect as part of its interactive test suite. It's for more than just automating a workflow!

gdb has a batch processing mode and its own scripting language with conditionals, loops, etc., so you could do this entirely with gdb scripting, probably. I've had good luck using gdb scripting for various things, notably conditional-ish breakpoints that printed some debugging info only under certain complicated conditions. (I do concede that if you know expect and not gdb scripting, except is quite likely easier, and it's possible expect is still easier if you know both, depending on the problem.)

gdb can also be scripted using Python. https://sourceware.org/gdb/onlinedocs/gdb/Python.html

Edit: and Guile

For those on mobile or on MacOS w/ Safari, the two bullets above are:

- to deploy commercial software whose configuration is only through an interactive terminal session and stored in an undocumented binary format

- to drive gdb to inspect a suspect Red Hat 6 "will not fix" GUI component that can go into an "impossible" pure cpu loop, to determine whether to kill it or whether it's busy in a more benign state.

I have used it to pass passwords to ssh

I recommend using Python's "paramiko" library for this -- it has this very neat feature to allow multiple commands. You can upload the script, then run it all in one connection.

Reply on news.ycombinator.com