Live data from Hacker News

Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool

blog.robertelder.org

91–100 of 106 posts

Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool

#91
post #7

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.

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.

What's the advantage of using paramiko/fabric vs something like Salt, Ansible, Chef, or Puppet?

Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool

#93
post #79

Earlier quoted context omitted.

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/T…

> 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?

I've taken online classes where they give you unit tests that use one set of inputs/outputs, when grading they'd use the same tests, but have a different set of inputs/outputs.

Early on there was one or two cases where subtle problems came up because the public set and private set accidentally tested things slightly differently, but the TA / prof was quick to respond.

Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool

#94

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/

Looking at the link I'm inclined to agree with Don.

While there are plenty of reasons to get salty towards high school kids, 'unfortunate web design' is probably not one of them.

Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool

#95
post #79

Earlier quoted context omitted.

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/T…

> 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?

I had a C class in college where we submitted homework with a program on a server. The program would compile the C code, run it with a bunch of inputs, and then report back if it passed (i.e. the output matched the expected output). The output was expected to be in exactly the correct format, so the submit program would helpfully print your output and the expected output so you could fix any formatting issues.

I got about 2 assignments into the class before I realized that I was being a chump. I wrote a C program that simply printed out the expected output, and submitted it. I received a passing grade on the assignment, so I took it further. I wrote a Perl script which would submit "int main(void){return 0;}", read the expected output, generate a C file that printed out that output, and submit it again.

Apparently the TA for the class never checked the submitted assignments and relied entirely on the submit program, so I was uncaught for a few weeks. My downfall was trying to make the Perl script as efficient as possible (I had extra time on my hands because I didn't have to do the C assignments!). I had run my Perl script a few dozen times while optimizing it, and apparently the TA received an email every time an assignment was submitted. He brought it up to the professor and I was called into his office. Luckily he was lenient and let me just redo the assignments :)

Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool

#97

Earlier quoted context omitted.

> 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.

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.

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!

>

Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool

#98
post #7

Earlier quoted context omitted.

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.

what's wrong with expect spawning ssh??

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.

Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool

#99
post #18

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 exampl…

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.

Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool

#100

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.

Expect questions do get answered on Stackoverflow though - http://stackoverflow.com/questions/tagged/expect
Post reply on HN