4 ms·

Expect is a last ditch tool that becomes less and less necessary as automation libraries and remote APIs become more and more common. The examples given are cut

Expect is a last ditch tool that becomes less and less necessary as automation libraries and remote APIs become more and more common. The examples given are cute but hardly representative of what expect is really for. The only times I've needed to use expect was to drive weird non-scriptable telnet-based remote systems and to automate unpackaging of intentionally-broken vendor-supplied self-expanding software archives that require some level of interaction. The point being if you want to create shortcuts to jump to specific locations in a man page or drive outdated appliances or open user-hostile zips, expect is the tool for you!

robertelder 10y ago
Do you have any links to examples of what it is really for? I've had a hard time finding code examples because the reasons listed at the bottom of the article.
- dekhn 10y ago
  Sure, let's say you want to remotely control a Cisco router with a serial interface. expect makes it really easy to remotely connect to the serial interface, wait for a prompt, send a command, and take a conditional action that depends on the response.
  - robertelder 10y ago
    I was thinking more of code examples. Expect is capable of doing much more than just the basic 'expect', then 'send' pattern. For example, this article: 'Most programmers don't know what Expect can do for them' http://wiki.tcl.tk/3913 http://wiki.tcl.tk/3913
    - lilyball 10y ago
      The article mentioned it's used for testing gcc and LLVM. If you want an example you can actually look at, it's also used for testing the fish-shell (fish-shell has other tests too, but expect is specifically used to actually test user-visible behavior, which makes expect the perfect tool for the task). You can find those tests in https://github.com/fish-shell/fish-shell/tree/master/tests https://github.com/fish-shell/fish-shell/tree/master/tests. The files of the form "foo.expect" are the tests (the "foo.expect.err" and "foo.expect.out" files are how it interacts with the rest of the testing infrastructure), and the file interactive.expect.rc provides a bunch of helper functions for the expect scripts, and in particular a standard way of looking for prompts (because the shell will redraw the prompt at various times, this function, coupled with the fish code in interactive.config, lets the expect scripts tell when it's the old prompt redrawn versus the new prompt after a command has been executed).
- deleted 10y ago
  [deleted]
kakwa_ 10y ago
I agree, expect is less and less useful, many vendors provides ways to automate deployment now. But "unautomatable" deployment is still happening. In some cases you can deal with it with some "printf 'line1\nline2\n'| vendor_command", but the vendor command may ignore stdin and you have to use expect. Having to automate that way is extremely brittle, stdout and stdin are very poor and unstable APIs. For example I remember some internationalized installers which gave stdout outputs according to your locales (lesson learned, export LC_ALL=en_US.utf8 before an expect script). And if one message is added or is changed, it can break... Personally, I tend to repackage badly shipped software (yay installanywhere crap...) in deb or rpm files, at least that way, I encounter issues before I deploy in production and I can update/remove this software easily and completely. However, it only solves part of the problem, if the configuration steps are interactive only, you've to resort to expect in production. Expect is less and less useful, it's a last resort solution, but when you need it's extremely helpful.
rodgerd 10y ago
Early versions of the local library web site we expect driving the AS/400 (IIRC) terminals on behalf of web interaction.
- sitkack 10y ago
  I can _hear_ the expect code running in lots of government IVR (interactive voice response) applications. Green scraping.

robertelder 10y ago

Do you have any links to examples of what it is really for? I've had a hard time finding code examples because the reasons listed at the bottom of the article.

dekhn 10y ago
Sure, let's say you want to remotely control a Cisco router with a serial interface. expect makes it really easy to remotely connect to the serial interface, wait for a prompt, send a command, and take a conditional action that depends on the response.
- robertelder 10y ago
  I was thinking more of code examples. Expect is capable of doing much more than just the basic 'expect', then 'send' pattern. For example, this article: 'Most programmers don't know what Expect can do for them' http://wiki.tcl.tk/3913 http://wiki.tcl.tk/3913
  - lilyball 10y ago
    The article mentioned it's used for testing gcc and LLVM. If you want an example you can actually look at, it's also used for testing the fish-shell (fish-shell has other tests too, but expect is specifically used to actually test user-visible behavior, which makes expect the perfect tool for the task). You can find those tests in https://github.com/fish-shell/fish-shell/tree/master/tests https://github.com/fish-shell/fish-shell/tree/master/tests. The files of the form "foo.expect" are the tests (the "foo.expect.err" and "foo.expect.out" files are how it interacts with the rest of the testing infrastructure), and the file interactive.expect.rc provides a bunch of helper functions for the expect scripts, and in particular a standard way of looking for prompts (because the shell will redraw the prompt at various times, this function, coupled with the fish code in interactive.config, lets the expect scripts tell when it's the old prompt redrawn versus the new prompt after a command has been executed).
deleted 10y ago
[deleted]

kakwa_ 10y ago

I agree, expect is less and less useful, many vendors provides ways to automate deployment now. But "unautomatable" deployment is still happening. In some cases you can deal with it with some "printf 'line1\nline2\n'| vendor_command", but the vendor command may ignore stdin and you have to use expect. Having to automate that way is extremely brittle, stdout and stdin are very poor and unstable APIs. For example I remember some internationalized installers which gave stdout outputs according to your locales (lesson learned, export LC_ALL=en_US.utf8 before an expect script). And if one message is added or is changed, it can break... Personally, I tend to repackage badly shipped software (yay installanywhere crap...) in deb or rpm files, at least that way, I encounter issues before I deploy in production and I can update/remove this software easily and completely. However, it only solves part of the problem, if the configuration steps are interactive only, you've to resort to expect in production. Expect is less and less useful, it's a last resort solution, but when you need it's extremely helpful.

rodgerd 10y ago

Early versions of the local library web site we expect driving the AS/400 (IIRC) terminals on behalf of web interaction.

sitkack 10y ago
I can _hear_ the expect code running in lots of government IVR (interactive voice response) applications. Green scraping.