Don Libes' Expect: A Surprisingly Underappreciated Unix Automation Tool • Hacker News Board

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

#101

Post by zwischenzug » Fri, Dec 09, 2016, 2:21 PM UTC

wyldfire wrote: post #90

zwischenzug wrote: post #29

Earlier quoted context omitted.

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/shut... which sets up a chef server.

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

Thanks for the tip. Laziness is a sin and a virtue.

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

#102

Post by dozzie » Fri, Dec 09, 2016, 11:09 PM UTC

pmoriarty wrote: post #91

wyldfire wrote: 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 the advantage of using paramiko/fabric vs something like Salt, Ansible, Chef, or Puppet?

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.

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

#103

Post by schlenk » Sat, Dec 10, 2016, 1:54 AM UTC

pmoriarty wrote: post #92

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.

Try the tcl channel on freenode. Expect is a Tcl extension.

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

#104

Post by tomcam » Sat, Dec 10, 2016, 4:53 AM UTC

8_hours_ago wrote: post #95

schoen wrote: post #79

Earlier quoted context omitted.

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

If I were the prof I'd fail you then hire you for my startup ;)

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

#105

Post by syngrog66 » Sat, Dec 10, 2016, 9:54 AM UTC

8_hours_ago wrote: post #95

schoen wrote: post #79

Earlier quoted context omitted.

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

in some alternate dimension you are Kirk taking a programming class. and this was his Kobayashi Maru moment. ;-)

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

#106

Post by joe563323 » Sun, Dec 11, 2016, 3:25 AM UTC

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.