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.
Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool
91–100 of 106 posts
Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool
#92Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool
#93Earlier 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?
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
#94Don 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.
Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool
#95Earlier 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 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
#96Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool
#97Earlier 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.
$ 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
#98Earlier 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??
Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool
#99I'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…
eg. Running the installer displays a licence agreement, then prompts to accept or decline.
Re: Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool
#100The 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.