21–30 of 106 posts
Earlier quoted context omitted.
what's wrong with expect spawning ssh??
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.
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?
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.
- 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 ;)
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 archive…
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.
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??
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.
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.
Earlier quoted context omitted.
what's wrong with expect spawning ssh??
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 retu…
It results in code like this:
https://github.com/ianmiell/shutit-chef-env/blob/master/shut...
which sets up a chef server.
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…
Silly backronym name aside, RANCID is a very handy tool and uses expect to do a lot of the 'dirty work'.