Most programmers don't know what Expect can do for them

https://wiki.tcl-lang.org/page/Most+programmers+don%27t+know+what+Expect+can+do+for+them

by pmoriarty • 7 years ago

153 53 7 years ago

kylek• 7 years ago

I winced at this as I've only ever used expect for dirty hacks like wrapping ssh (or telnet to strange devices without real management). I wouldn't discount it though, it's a decent tool when heavier machinery isn't viable.

stevekemp• 7 years ago

I used expect for wrapping router-setup, via telnet, back in the day. Hard to think what I'd use it for these days, thanks to puppet, ansible, docker, etc.

repairisntcheap• 7 years ago

One of my most fond programming experiences was using tcl/expect to create a custom web interface for an IBM Tivoli tape library. The stock web interface was too expensive for a college with a few thousand users, and didn't provide adequate access control to allow our users to restore ONLY their own files.

Yes, wrapping a telnet session is a hack... But it was a hell of a hack that did everything we needed!

foobar_2• 7 years ago

I'd still use expect instead of docker/ansible/salt ... if I could get away with it.

marmaduke• 7 years ago

Those aren't alternatives; you'd create a Docker image with expect installed, for example.

rmetzler• 7 years ago

Wrapping expect in an Ansible playbook is really useful though.

emmelaich2• 7 years ago

There is an expect module included in Ansible.

Backed by pexpect of course.

mzs• 7 years ago

I wish there was something like expect that was like, "ok I've done what I needed to init, now get out of the way." I've always had to create a loop that just reads and writes everything eventually. Maybe I could ldpreload a tcl interpreter and change some pointers but yikes.

solresol• 7 years ago

What's wrong with the interact function?

_ph_• 7 years ago

Isn't that what interact is meant to do?

https://wiki.tcl-lang.org/page/interact

jraph• 7 years ago

If I understood correctly, you may be able to do that using pexpect and the interact method.

    import struct, fcntl, termios, signal, sys

    def sigwinch_passthrough (sig, data):
        s = struct.pack("HHHH", 0, 0, 0, 0)
        a = struct.unpack('hhhh', fcntl.ioctl(sys.stdout.fileno(),
        termios.TIOCGWINSZ , s))
        if not child.closed:
            child.setwinsize(a[0],a[1])    
    
    child = pexpect.spawnu("sh", args, encoding='utf-8', logfile=sys.stdout)
    signal.signal(signal.SIGWINCH, sigwinch_passthrough)
    child.expect_exact("...")
    child.logfile = None # Otherwise, interact raises an Exception
    child.send("...\n")
    child.interact()

gnachman• 7 years ago

I created coprocesses in iTerm2 because I missed Expect but I also hated Expect because it had a very expect-y way of doing things that never felt comfortable (though I shan't say a nasty word about Tcl!) Also, what mzs said about "now get out of the way".

sus_0072• 7 years ago

TIL, Tcl is pronounced as Tickle, but not Tee-see-el.

bch• 7 years ago

Either is fine and used. Joke is “tickle” among the initiated/familiar, tee cee ell if you’re talking to management. However, never name a file test.tcl, regardless of how you pronounce it.

sus_0072• 7 years ago

I'm a total stranger to the Tcl universe, but I'm curious what does happen if a programmer names a file "test" ? Some kind of conflict, bug, error ?

computerfriend• 7 years ago

I ended up rewriting most of my Expect code in Pexpect and found it both nicer to write and much more robust.

based22• 7 years ago

https://github.com/pexpect/pexpect Python module for controlling interactive programs in a pseudo-terminal

tyingq3• 7 years ago

There's also Perl's Expect.pm. I know Perl isn't popular here, but it excels in this sort of use case. The compact syntax for regexes on responses makes it a good match for expect scripting. It can also be paired with IO:Pty for some advanced stuff.

DrJosiah• 7 years ago

You are fighting the good fight, I kept trying and failing. Thank you.

http://code.activestate.com/recipes/440554-module-to-allow-a... https://www.python.org/dev/peps/pep-3145/

noisy_boy• 7 years ago

I need to connect to various machines throughout the day and as a first step, need to sudo to a service account. Expect has been a godsend to automate the interaction/input my credential (I know that it is far from being the most secure thing but the convenience of typing an alias and being connected including sudo is significant).

elldoubleyew• 7 years ago

I use expect to write little "drivers" for serial devices all of the time. I don't have a lot of experience with hardware and often its the easiest way to set up an interface. I never really knew how much it could do until one of my coworkers recommended it to me for this purpose one day.

tarkin2• 7 years ago

If, like me, you still weren't sure what Expect does then this is a great explanation https://www2.lib.uchicago.edu/keith/tcl-course/topics/expect...

falsedan• 7 years ago

The test suite for the grody old IRC bot a few jobs ago was written in Expect. One intern season we set a project to, when announcing a new PR was published, to format the primary reviewer’s handle slightly. It ended up taking 3 days to update the tests, understanding expect, then writing a filter to strip out IRC color codes.

ohazi2• 7 years ago

Whenever I need to "screen scrape" an interactive console application, I usually end up running the process under tmux and interacting with it via Python after wrapping send-keys and capture-pane.

kragen2• 7 years ago

Do you know there's an expect clone for Python?

ohazi2• 7 years ago

I do now. Thanks!

based22• 7 years ago

https://docs.ansible.com/ansible/latest/modules/expect_modul...

https://github.com/ronniedong/Expect-for-Java

doctor_eval• 7 years ago

I’ve written so much code in Tcl/Tk/Expect - but it was all pre-Java; literally before Java 1 was released. Tk was used in lots of Linux apps, most notably Zircon, an awesome IRC client.

I used to think that knowing Tcl was a kind of super power. It was incredibly productive. It was far better for quick scripting than either bash or awk - but large programs could get somewhat unmanageable.

It would be great to see a renaissance of TCL usage, though I’d be pretty much re-learning it today.

ghettoimp• 7 years ago

TCL is still in use everywhere in hardware development. Practically every EDA tool has a TCL interface.

I'm afraid I don't share your fondness for it. :)

tyingq3• 7 years ago

It's also in other places, like F5 load balancers.

cobbzilla• 7 years ago

I used expect long ago, it was fun but a bit cumbersome.

Quite recently I was working on some python that used netmiko, which is similar but more ssh-oriented.

Having used both, I don’t know when I’d ever use expect. Maybe if there was no python available for some reason.

The developer ergonomics on netmiko are just better. It’s not anything about python vs tcl, it’s that netmiko “does more out of the box”, and expect is a bit lower-level.

denton-scratch• 7 years ago

I tried to use BATS (Bash Automated Testing System) with Expect and Tcl to test a series of interactive scripts. It turned out to be something of a rabbit-hole. I didn't spend long enough on the task to get really good at it, and the result was tests that were hard to read (i.e. not what you want). Perhaps there was a 'wrong tool for the job' factor at play.

DictumMortuum• 7 years ago

Working in a quite popular b2b betting company. TcL is used for much of the backend and development is still active today. Expect is used , too.

INTPenis• 7 years ago

I've used Expect a couple times in the last 8 years. First to make backups of Cisco configurations into version control. And second by Ansible (indirectly it's used to read the sudo prompt).

So more people use expect than know it.

The issue I feel is that it's flimsy to wait for some expected output. I mean, it's even in the name! Especially when working with unknown APIs like Cisco IOS CLI.

So whenever I've done manual expect coding I've always felt very much out of my element and out of control. I am a control freak btw.

It works while it works but as soon as something unexpected happens it all goes to sh*t.

rowanG0772• 7 years ago

Doing anything with expect is basically only coding for the happy path. It's fine for some throw away script but as soon as you need any kind of reliability it's useless.

GhettoMaestro2• 7 years ago

Have you ever stopped and asked yourself: What is a conditional statement?

rowanG0772• 7 years ago

Have you ever asked yourself if an API can return an infinite amount of responses how many conditional you would need to handle that?

The output of a terminal is just simply too unstructured to work in any high reliability environment.

marktangotango• 7 years ago

Lots of talk about TCL in this thread. Everyone should be familiar with the TCL/Guile and GNU scripting story. Also Ousterhout’s dichotomy is a useful concept to understand:

https://en.m.wikipedia.org/wiki/Ousterhout%27s_dichotomy

tyingq3• 7 years ago

Ousterhout also co-invented raft distributed consensus.

emmelaich2• 7 years ago

The root of the problem is that too many programs require a tty.

rubicks3• 7 years ago

This. Why do programs do this when they don't have to? I'm genuinely asking here; I'm trying to understand the thinking that motivates this kind of decision.

bachmeier• 7 years ago

tcl brings out cries of "dead language" in a way that few other languages do. I'd not hesitate to write a tcl stript today, knowing that it'd still run correctly when I die.

Just in the past week, I've heard tcl, ruby, perl, and java all declared dead. Oh well. Internet comments are cheap and meaningless.

eesmith• 7 years ago

TRAC is dead. (Now I hope to hear from people using Mooers' TRAC in production code. Or CART or SAM76. I have talked to people who used TRAC back in the 1980s.)

skybrian• 7 years ago

I do know what it can do, but it seems like a specialized tool for screen-scraping command line apps that don't have a proper API. That seems like a rather unusual task these days?

rubicks3• 7 years ago

I've wrapped expect scripts around prompt-happy config scripts supplied by third-party vendors. What they intend to be idiot-proof usually ends up as an unwieldy tool that takes no options and/or assumes bad defaults. The vendor didn't intend for it to be run more than once per site installation, but such intentions don't play nice with disposable environments like VMs and/or containers.

rubicks3• 7 years ago

Expect is nothing short of a blessing for those who need to automate tools that actively resist automation. When some janky cli script decides to read the tty and not stdin, I reach for expect.

lcall• 7 years ago

For years I thought "I should learn to use expect...", and finally I used it for ~ integration tests for a project (http://onemodel.org - my AGPL, highly efficient desktop- and keyboard-oriented personal knowledge organizer that I use every day, slow progress lately but lots of plans...), and: expect is very useful, and has depth.

jolmg• 7 years ago

I used expect once some years ago, but changed to using ruby's #expect method[1]. I think the reason I changed was because, in TCL, some functions seem to keep track of stuff by setting variables in the caller's scope. So, if I took some code I wrote and defined a new function with it, substituting the code with a call to the new function, stuff would break because calls to predefined expect functions wouldn't have the same caller's scope anymore.

I wish I had a concrete example to share so someone here could confirm, but like I said, it was some years ago.

[1] https://ruby-doc.org/stdlib-2.6.4/libdoc/pty/rdoc/IO.html#M0...

Most programmers don't know what Expect can do for them

Related Stories