12 ms·

Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool

• seiferteric 10y ago
  Expect is cool, I have used it in the past as well as the expect perl module, but in my opinion is always a suboptimal way to automate things. It's always better and more robust to have a proper interface to script things instead of relying on matching brittle text/regex responses and timers and such. Of course sometimes it's not possible, so expect comes in handy.
  • wyldfire 10y ago
    I 100% agree. If I can use paramiko/fabric or something similar, I prefer it way more than expect. If you have a slave device over RS232, expect is probably your only option. But if that remote item is running sshd, you are way better off without expect.
    • crististm 10y ago
      what's wrong with expect spawning ssh??
      • jstimpfle 10y ago
        I think expect is often used to have it enter username and password "interactively". But it's easier and more robust to just use the public-key auth facility that is built-in to ssh.
        • Karunamon 10y ago
          Not always possible. The problem is that ssh lives in the mythical land of perfect security, where people never need to do unsafe things in order to get their jobs done. Hence keys silently not working without "correct" permissions, passwords not passable on the CLI, inconsistent type-yes-to-override behavior, and other user-hostile design choices. I love openssh, but it's a real pain in the ass sometimes.
          • jstimpfle 10y ago
            I don't have any of these problems. Just don't use passwords non-interactively, but use public key auth. Also, as any sane program, (open)SSH does not ask you to type anything when running non-interactively in a script (more precisely, when no terminal is present).
            • Karunamon 10y ago
              If you don't have any of those problems, you're very lucky. Again, ssh is designed with the assumption that people never have a reason to do unsafe things.
          • seiferteric 10y ago
            there is also sshpass for supplying password, as well as using a languages library like paramiko for python which I believe allows you to supply a password. It would take more than password auth to force me to use expect these days :)
        • crististm 10y ago
          This isn't expects' fault. If you did not want to record the password in the script then ssh manually and then continue the script from there (e.g. with 'interact' command)
      • wyldfire 10y ago
        expect scripts in general are brittle IMO. The general design is: "look for this and then that and then this. If at some point you stall along this path for more than X seconds, something must have gone wrong, abort." Well, I maintain that the characters in the stream aren't as good success criterion as the stack of exit codes among the tasks. So if I "ssh remotefoo /tests/the_test.sh" it is the_test.sh's job to return 0 if it succeeded and nonzero otherwise. ssh will return 0 if the remote script returns zero, so I can count on that. But if the host is busy sometimes and the_test.sh takes 91 seconds on a heavily-loaded day but 37-45 seconds normally, I might encode the wrong timeout in my expect script. Things like /etc/issue or /etc/motd or PS1 should have no bearing on my test results. But if someone writes the text "Password:" or "Username:" or some other similar content in there, my expect script might choke on it.
        • zwischenzug 10y ago
          Indeed, which is why in ShutIt I used some tricks with the prompt to determine whether a command was finished, and then (optional, but defaulting) checks on exit codes to determine success/failure. It seems to work pretty well, and no need to specify what it expected. It results in code like this: https://github.com/ianmiell/shutit-chef-env/blob/master/shutit_chef_env.py#L83-L88 https://github.com/ianmiell/shutit-chef-env/blob/master/shut... which sets up a chef server.
          • wyldfire 10y ago
            Aside: the bare except clause used here [1] is a bad habit. You should try to avoid it. Python raises things like NameError and TypeError for simple design problems like mistyping variable names. It's extremely rare that you can handle errors like that. Your "except:" would attempt to handle and effectively mask bugs like this. [1] https://github.com/ianmiell/shutit-chef-env/blob/master/shutit_chef_env.py#L56 https://github.com/ianmiell/shutit-chef-env/blob/master/shut...
            • zwischenzug 10y ago
              Thanks for the tip. Laziness is a sin and a virtue.
      • mypalmike 10y ago
        Why would you mix expect with ssh? Most of the time, if you can ssh, you can use an exec channel ("ssh somehost somecommand"), so you shouldn't need to pretend to be typing characters and waiting for prompts.
    • seanp2k2 10y ago
      I've used paramiko + expect to automate distributed benchmarking + results gathering. I can say that while it ultimately worked, Curse That Thing In Particular. It was so so so fiddly to get everything working, and very fragile + output-dependent. https://github.com/ip2k/Mad-Science?files=1 https://github.com/ip2k/Mad-Science?files=1 I wrote this a long time ago and it's ugly. It totally worked and let our company find more optimal hosting configs.
      • lamontcg 10y ago
        > while it ultimately worked, Curse That Thing In Particular "Things Only 90s SysAdmins Will Remember" Expect is mostly a tool of last resort when a utility has silly prompts that you can't bypass by hitting it with command line options like `-y` and stuff.
      • knownothing 10y ago
        What does the `?files=1` bit do?
        • wyldfire 10y ago
          It appears to omit the repo's description and some of the buttons.
    • pmoriarty 10y ago
      What's the advantage of using paramiko/fabric vs something like Salt, Ansible, Chef, or Puppet?
      • dozzie 10y ago
        Paramiko is a Python API for SSH client, so it's not comparable to either of the rest. Fabric itself is a poor man's badly implemented RPC for sysadmins: you send commands and receive output and result codes. Fabric wraps this in a Python API, so you can react to how your operations run. Salt and Ansible are similar to Fabric (and "poor man's badly implemented RPC" comment applies to them as well), but they also define some higher level tasks, like "have X package installed". All three have the operations defined at the call initiator and return synchronously, when all the work is done. Then there are CFEngine, Puppet, and Chef. Every managed server runs an agent that periodically executes some rules. CFEngine and Puppet have their own DSLs, and Chef uses general purpose language (Ruby), what I consider a bad fit. These work asynchronously, as you don't push the rules to the servers, but change them in their distribution point and wait for servers to pick up the update.
  • stcredzero 10y ago
    Expect is cool, I have used it in the past as well as the expect perl module, but in my opinion is always a suboptimal way to automate things. When I was a graduate Comp Sci TA in the 1990's, it was the perfect way to automate grading the Unix shell that the Systems Software class was supposed to write. Effectively, I was also writing a regression/functional testing system for the class. I explained that the Expect/Tcl script was going to be used to grade their project, and I provided the code. One of my students said I was the best TA ever! There were a few students who complained that they shouldn't be marked off for a feature breaking, because it had worked a week or two ago. There were a few students who never figured out that the script was going to be used to grade their project, even though I provided weekly email updates explaining this.
    • vram22 10y ago
      Nice use of expect. I expect (pun intended, though realized after the fact) that you used it to simulate sending user input to their shell? and checking that the shell's response was as expected? (not doing the second on purpose either, honest, it just seems the right word to use).
    • schoen 10y ago
      > I explained that the Expect/Tcl script was going to be used to grade their project, and I provided the code. If it's deterministic, is there a risk of someone just writing a second Expect script (instead of a solution to the programming exercise) that interacts with yours and gives the replies that you want?
      • stcredzero 10y ago
        Sure, but I didn't necessarily say that I'd give them the final version of the script and all of the tests.
        • schoen 10y ago
          Oh, I see!
      • 10y ago
  • vram22 10y ago
    Yes, expect is really cool. I haven't used it heavily, but had used it some earlier, to automate small command-line tasks to good effect. Also: 1. I had read much of Don Libes' Expect book. He had a unique style of writing in that book. Hard to describe, partly since it was some years ago, and partly because I can't find the words for it. But I think anyone reading the book would notice the style after reading a few pages. It was not a bad style by any means, just ... something different. 2. I've read that expect was (maybe still is) used heavily in the electronics/EDA industry, though I am either not sure or don't remember how exactly they use it, or rather, for what. And also maybe it was used heavily by GNU software for testing. Maybe someone here can confirm.
  • flukus 10y ago
    Is it intended to automate things? It looks like it's meant to save typing with interactive things.
• cafard 10y ago
  Expect is the reason that I first learned Tcl. I haven't used it quite a while, though.
• setq 10y ago
  Expect is great for persuading things, particularly poorly written Java monoliths that use text interactive installers, to play nicely with ansible. On more than one occasion it has been tasked with handling one. You run autoexpect first to record what you want it to do on a dry run, then tidy up the generated expect script, then plug it into ansible as a raw task. Granted this shouldn't be a problem in 2016 but some vendors are idiots. But thanks to expect my life is a little more comfortable :)
• zwischenzug 10y ago
  I use pexpect as the basis of an automation framework I use a lot: https://github.com/ianmiell/shutit/blob/master/README.md https://github.com/ianmiell/shutit/blob/master/README.md Recently I used it to migrate an etcd cluster within OpenShift reproducibly: https://medium.com/@zwischenzugs/migrating-an-openshift-etcd-cluster-a7e43e861d61 https://medium.com/@zwischenzugs/migrating-an-openshift-etcd...
  • zwischenzug 10y ago
    PS I also wrote autopexpect, which is based on another underrated tool (autoexpect) https://github.com/ianmiell/autopexpect https://github.com/ianmiell/autopexpect http://expect.sourceforge.net/example/autoexpect.man.html http://expect.sourceforge.net/example/autoexpect.man.html
    • SEJeff 10y ago
      Oh this is really nice! I've used pexpect (and pxssh) extensively along with expect in a previous lifetime. I'd always meant to write an "autopexpect" or "autopxssh" and never did. Thanks!
      • zwischenzug 10y ago
        Glad to hear it! It's very raw, so please do contribute if you can.
• michaelsbradley 10y ago
  Don Libes' Exploring Expect[1] is a devops classic (if there is such a thing). It would be nice if O'Reilly would make the text (completely) freely accessible[2], as they have done with some of their other older titles[3]. See also the Caius framework[4]. [1] http://shop.oreilly.com/product/9781565920903.do http://shop.oreilly.com/product/9781565920903.do [2] https://www.safaribooksonline.com/library/view/exploring-expect/9781565920903/ https://www.safaribooksonline.com/library/view/exploring-exp... [3] http://www.oreilly.com/openbook/ http://www.oreilly.com/openbook/ [4] http://caiusproject.com/ http://caiusproject.com/
• stevenhuang 10y ago
  Expect was great when I had to automate ssh'ing into a bunch of different machines with generated passphrases. Not the best for security, but the machines were in a private network and key auth was not used at the time. Saved a lot of typing!
• jashmenn 10y ago
  For folks like me who read this and want to use `autoexpect` on OSX: brew install homebrew/dupes/expect # find the expect/tcl path with this command otool -L /usr/local/bin/expect export TCLLIBPATH=/usr/local/Cellar/expect/5.45/lib autoexpect
• sheraz 10y ago
  I remember using expect to make my US Robitics modem to dial-up and get online, and to authenticate past RADIUS servers. good to see this old util get some new light here.
• chrismealy 10y ago
  I gave up on expect in 1990s. It always almost but not quite worked. Is it better now?
• pron 10y ago
  Many years ago I used Expect to write a multi-host shell: https://github.com/pron/sysman https://github.com/pron/sysman
• erikb 10y ago
  I used pexpect (a Python expect like library) in my master thesis. Was far from perfect but much better for what I wanted than all the other libraries I've tried.
• danso 10y ago
  I'm going to try this out on my own because what I read in the comments makes me think I will find use for it, but if I had to be honest, I did so because of the HN comments. The OP was clearly written and nicely formatted, but as someone with moderate CLI/Bash experience (I do almost all of my data processing via Bash programs and pipes), I didn't really understand what `expect` does. Maybe I needed a simpler example, because I don't uss most of the other parts that are in the example, such as `interact` and `send`. As a Pythonist/Rubyist, I have the added baggage of associating `expect` with unit/line testing. Maybe expect is not for me, but given the title, I would've loved to see maybe a couple paragraphs of why `expect` is underappreciated...that is, what do typical Unix programmers use instead, because they're ignorant of expect. Much easier for me to understand the perspective of ignorance :)
  • qwertyuiop924 10y ago
    Expect is a TCL-based command-line scripting tool. It's designed for scripting things that don't have a scripting interface, and weren't designed to be scripted. Essentially, expect scripts run a program, send it some input, look for some regexes on stdout, and then send more input, which may change depending on what the regex matches. And so on. This is useful, say, if you have a package management tool that requires you to explicitly confirm every update. Or if you want to automatically drive a shell on a remote machine over SSH, and you can't use ssh -c for some reason. You don't need it often. But when you do, it's very useful.
  • shermanyo 10y ago
    The simplest but one of the most useful example I've run into is in scripts that run an installer that forces a keypress. eg. Running the installer displays a licence agreement, then prompts to accept or decline.
• skywhopper 10y ago
  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).
• bxrxaxdx 10y ago
  OMG I have been burned by this so many times. Expect itself is a cool piece of technology and works as well as anyone could hope. However, every time I've tried to use it for anything the solution ends up being super flaky. I think trying to automate text interfaces like this is just fundamentally unreliable.
  • chriswarbo 10y ago
    I think of it in the same way as screen scraping Web pages, or writing buffer-heavy Emacs Lisp: - If there are alternatives, they'll usually be better - It'll still be around when there are no alternatives - Some tasks (e.g. "toggle foo mode") are inherently easier than others (e.g. "press up five times and hope that's enough") - Some tasks need frequent maintenance and tweaking (e.g. as i/o formats change, program features are added/rearranged, shell environments are tweaked, etc.) - Some tasks work so well that they're taken for granted for a decade, and it's only when you want to tweak some part that you remember how truly horrifying the implementation is ;)
• chriswarbo 10y ago
  > Many of them are actually dead links, or projects with less than 40 stars on GitHub. Off topic, but how long has "stars on github" been an indicator of software quality/longevity/usefulness/etc.? How many "stars on github" does Expect have?
  • jquast 10y ago
    pexpect (python variant of the same) has 750 stars, so its popular. people have just dropped tcl in favor of perl and later python and others ... I don't personally like tcl anymore, but I programmed tcl/expect in the 90's and enjoyed it a lot. I now co-maintain pexpect.
• airesQ 10y ago
  I've used expect to automate distro upgrades at some point, as we needed to upgrade a couple hundred machines. During testing I kept finding edge cases. Then I eventually accounted for most of the edge cases, and gave a default answer for "unknown" edge cases. It sort of works, but I would like to have more confidence in the process. Then again, I never felt that the problem was expect, expect does its job, and does its job reliably. The problem usually boils down to unexpected prompts (pun unintended). I've also used pexect in Python for testing, no complains there. In fact at some point somebody tried to refactor this particular python program to use Paramiko, but decided to keep pexpect after running into some problems.
• RHSeeger 10y ago
  Long ago, I had to write a utility to backup the configurations settings from all the network devices in a given network. At the time, the network consisted of many, many different types of routers, switches, and the like. For many of the devices, there was a way to fetch the config but it required logging into the device (generally telnet) and navigating a menu to "send" the config somewhere. Using expect to do that was a fantastic way to handle it. There's also a number of cases where you want output from a command line program "as if run by a user at a terminal". For some programs, they change the output (ie, removing color codes, etc) if the output is not going to a terminal. Expect does a fantastic job of pretending to be a terminal. Also, it's Tcl, and I love Tcl. It's (possibly tied) at the top of my list for languages. So much fun and more flexible than anything that doesn't support lisp level macros.
  • EvanAnderson 10y ago
    In case somebody's interested in a tool that does the kind of thing you describe re: network devices after reading your comment I thought it might be helpful to include a link RANCID: http://www.shrubbery.net/rancid/ http://www.shrubbery.net/rancid/ Silly backronym name aside, RANCID is a very handy tool and uses expect to do a lot of the 'dirty work'.
• geff82 10y ago
  I used expect heavily at several clients in the past and have never seen someone else use it. I never used it as a precise tool, rather as a Sledgehammer. I think I remember I used Expect to script remote machines (expect was literally the "programmer") when everything else failed and was "prevented" due to policy. I guess my script was also non-compliant, but noone complained.
  • ianmcgowan 10y ago
    I've done the same thing, and on the windows side of things AutoIT (https://www.autoitscript.com/ https://www.autoitscript.com/) is similarly flexible when all else fails. It's not pretty, but arguably is a good example of the hacker ethic.
    • EvilTerran 10y ago
      For Windows, I like AutoHotKey - IIRC, it started out as an open-source alternative to AutoIt, but has since grown a significant amount of functionality of its own: https://autohotkey.com/ https://autohotkey.com/
• digi_owl 10y ago
  I find myself thinking about autohotkey.
• joshaidan 10y ago
  Reading the examples in the man page brings me back to a different era of modems and BBSs: "The name 'Expect' comes from the idea of send/expect sequences popularized by uucp, kermit and other modem control programs." "Cause your computer to dial you back, so that you can login without paying for the call." "Start a game (e.g., rogue) and if the optimal configuration doesn't appear, restart it (again and again) until it does, then hand over control to you." "Connect to another network or BBS (e.g., MCI Mail, CompuServe) and automatically retrieve your mail so that it appears as if it was originally sent to your local system." "Carry environment variables, current directory, or any kind of information across rlogin, telnet, tip, su, chgrp, etc."
• znpy 10y ago
  Speaking of surprisingly unappreciated unix tools, I recently started reading the documentation of the gnu info package, and I must say, that is really impressive. if you didn't already, I highly recommend you type 'info info' in your terminal and spend half an hour learning how to use it. Plus, if you are an emacs user, the emacs manual is bundled with emacs in info format, and you can obviously read info documents in emacs too. Reading the gnu emacs manual inside emacs is a game-changer.
  • andlrc 10y ago
    `info` also contains a lot of historical notes, i.e. $ info Groff | awk '$2 == "History"{f = 4};f && f--' RS= ORS='\n\n' 1.2 History =========== 'troff' can trace its origins back to a formatting program called 'RUNOFF', written by Jerry Saltzer, which ran on the CTSS (_Compatible Time Sharing System_, a project of MIT, the Massachusetts Institute of Technology) in the mid-sixties.(1) (*note History-Footnote-1::) The name came from the use of the phrase "run off a document", meaning to print it out. Bob Morris ported it to the 635 architecture and called the program 'roff' (an abbreviation of 'runoff'). It was rewritten as 'rf' for the PDP-7 (before having UNIX), and at the same time (1969), Doug McIllroy rewrote an extended and simplified version of 'roff' in the BCPL programming language. In 1971, the UNIX developers wanted to get a PDP-11, and to justify the cost, proposed the development of a document formatting system for the AT&T patents division. This first formatting program was a reimplementation of McIllroy's 'roff', written by J. F. Ossanna.
    • kazinator 10y ago
      I'm well familiar with Awk RS="" paragraph mode and all, but I'm scratching my head why f = 4 to fetch three paragraphs. [Edit]: Indeed, I ran your command verbatim and obtained one more paragraph: When they needed are more flexible language [...]. You sneaky devil!
      • andlrc 10y ago
        > You sneaky devil! He he. Never copy/paste shell code found on the internet :-)
• daenz 10y ago
  Shameless self promotion: if you want to automate subprocesses with python in an intuitive way, give sh a try: https://github.com/amoffat/sh https://github.com/amoffat/sh
  • spangry 10y ago
    Man, I was so happy when I discovered your library. It's how I always felt subprocess should be. With split('\n') and basic string parsing there's little that can't be automated with sh. Keep up the good work!
    • daenz 10y ago
      That makes me happy to hear, thanks!
• hydandata 10y ago
  Expect can be a lifesaver when you cannot use your usual go-to tools like Ansible etc. especially with legacy setups where you cannot tweak stuff much. I have successfully used it combined with tmux for automated multi-term like functionality, deployment verification and other chores to save a lot of $ for my company. I do try to keep my Expect scripts as simple as possible though, just so I do not have to remember too much since I do not work with TCL anywhere else.
• ChuckMcM 10y ago
  This tool keeps the command line interpreter (CLI) alive. Sysadmins everywhere can glue hundred different systems from a hundred different vendors together if they have CLI and the sysadmin has access to a machine that runs expect(1). There are many stories of complex infrastructure being taken down by new firmware on routers or switches that change the order of parameters in a command :-)
  • kazinator 10y ago
    Rather, this tool keeps alive systems that do not have easily scriptable command interfaces, and must be driven at the character-level through their interactive visual interfaces. If the system has a CLI, you write a script in that CLI; you don't write an expect script. Sometimes systems have CLI, but only behind a remote access wall (telnet, serial, ...); then you might use expect---because there is no way to upload a script and dispatch it.
    • ChuckMcM 10y ago
      > Sometimes systems have CLI, but only behind a > remote access wall (telnet, serial, ...); then > you might use expect- All managed switches, all routers, and all PDUs pretty much.
      • kazinator 10y ago
        Well, perhaps not quite all routers, like this cheap consumer device: $ ssh root@router uname -a root@router's password: Linux router 2.4.20 #1 Sun Jun 27 20:13:35 PDT 2010 mips GNU/Linux The only use case for Expect here is typing in the password, which we can eliminate by administering some SSH keys.
        • mypalmike 10y ago
          And then there are the "enterprise switches" from at least one major vendor, whose crappy ssh implementation only supports a single tty channel (no exec channels), so you have to run expect anyhow. :-( $ ssh root@router uname -a Connection closed by shitty ssh implementation. $ ssh root@router Welcome to router! >
• wangchow 10y ago
  Tcl (upon which Expect is built) is under-appreciated too. It's a neat language how strings behave as a sort of polymorphic data structure (can be dicts, lists, etc). Under the hood they get optimized based on usage.
• danielweber 10y ago
  Every once in a while I find I need to pull out Expect and it's like using an old friend.
• a3n 10y ago
  https://en.wikipedia.org/wiki/Don_Libes https://en.wikipedia.org/wiki/Don_Libes
• a3n 10y ago
  I used to use expect to automate testing a medical device over telnet.
• teddyknox 10y ago
  Don Libes' daughter went to my high school, and I was working as the "webmaster" for the high school newspaper's website at the time. He would ruthlessly criticize via email the product our self-taught and earnest 2010-era PHP web development. I am not a fan of Don Libes. For those interested, the website was/is: http://theblackandwhite.net/ http://theblackandwhite.net/
  • kazinator 10y ago
    He just had high ... expectations, that's all.
  • clifanatic 10y ago
    Looking at the link I'm inclined to agree with Don.
    • GFK_of_xmaspast 10y ago
      While there are plenty of reasons to get salty towards high school kids, 'unfortunate web design' is probably not one of them.
• tluyben2 10y ago
  I have used this a lot in the past but don't have the need for it anymore. It was incredibly useful and I would've died of overwork if I did not have it back then...
• kazinator 10y ago
  I'm calling expect dynamically out of CGIT (the git repo serving CGI program). The expect script runs Vim in pseudo-terminal, to load a source file and syntax-colorize it via :TOHtml. That HTML is then integrated into the file view generated by CGIT. This is not done for every file type; a master shell script dispatches different coloring strategies based on suffix.
  • Somasis 10y ago
    You know, cgit does come with two example syntax highlighting scripts... :)
    • kazinator 10y ago
      That's correct. (I think the old version I'm using maybe only with one.) That script is what I hooked my custom logic into.
• deleted 10y ago
  [deleted]
• jtcond13 10y ago
  Any reason Expect isn't included on many of the common Linux distributions? That kind of limits its use, for many of us.
• hughw 10y ago
  A friend taught me about expect by giving me this expect script for logging into our vpn. It automates login using Cisco Anyconnect on a Mac. pw=c3-f3-341a spawn /opt/cisco/anyconnect/bin/vpn connect vpn.example.com expect "Username:*" { send "myname\r" } expect "Password:*" { send "$pw\r" } interact
• jquast 10y ago
  Noah Spurrier did a great job with pexpect, which i helped port to python 3 and add unicode support. I've been in love with pty's in general since the mid 1990's, and naturally found myself maintaining a highly visible python project about pty's. love this stuff.
• kazinator 10y ago
  I did an "expect like" thing with my TXR language for scraping documents. Namely IMAP authentication: http://www.kylheku.com/cgit/tamarind/tree/auth.txr http://www.kylheku.com/cgit/tamarind/tree/auth.txr All that's missing is the pseudo-tty manipulation and whatnot to do that sort of thing over TTY-based sessions. Timeouts are handled by setting up timeouts at the socket level. These turn into an exception, which we catch and convert to a pattern matching failure.
• kazinator 10y ago
  Things only 80's admins and hackers might remember: similar to Expect, some terminal emulation + serial communication programs for PC's came with languages for automation, resembling Expect. Expect might have been inspired by that sort of thing. I had experience coding in two of them for DOS PC's: ProComm Plus's ASPECT language ("Pascal-ish" flavored), and a C-like language called Salt built into Telix. I mostly used the very popular Telix for my personal use, but a law firm for whom I did some IT contract work used Procomm Plus for connecting to various databases available over dial-up (e.g. local land title registry). I wrote a bunch of ASPECT code to automate their scraping tasks: log in, look up this and that, save in a file, that sort of thing. https://en.wikipedia.org/wiki/Telix https://en.wikipedia.org/wiki/Telix https://en.wikipedia.org/wiki/Procomm_Plus https://en.wikipedia.org/wiki/Procomm_Plus
• jquast 10y ago
  I wrote a brief article about pexpect, driving into the difference of why we chose to use a pseudo-terminal in some special cases of automation, https://jeffquast.com/post/terminal_1/ https://jeffquast.com/post/terminal_1/
• pmoriarty 10y ago
  The worst thing about expect is that it doesn't have an IRC channel on which you can find knowledgeable people to help you out when you're stuck.
  • cmacleod4 10y ago
    Expect questions do get answered on Stackoverflow though - http://stackoverflow.com/questions/tagged/expect http://stackoverflow.com/questions/tagged/expect
  • schlenk 10y ago
    Try the tcl channel on freenode. Expect is a Tcl extension.
• deleted 10y ago
  [deleted]
• joe563323 10y ago
  The lesson learned from expect is to not name a software with generic name, it is very hard to search on internet regarding the usage problems and in forums.