As an intern, I used expect in my first job to create a monitoring system for ~ 200 L3 Routers in a private network. Eventually I learned about SNMP and also that I probably should Google "How to X" before rolling out my own solution for anything.
Interestingly, I did something very similar in my first job, though it included backing up configurations and the like. It's worth noting that a lot of routers (at that time) didn't really support much in the way of SNMP. As such, one had to navigate menus to get to the necessary options; and nothing is as potent as Expect at that kind of thing.
About 20 years ago, I built a system for L3 router configuration using expect. It basically allowed support people to move a port's VLAN and change its status from a web app. It was for a local telco and they used it for a couple of hospitality / hotel customers, IIRC.
I think the library is quite elegant because it essentially does very little itself. It's implemented almost entirely using the "partial match" feature of PCRE: https://pcre.org/current/doc/html/pcre2partial.html This means it can use the super-powerful regexps in PCRE, while itself being only a few hundred lines of code.
What's the reason behind writing automation tooling in C instead of higher level languages? The usual (portability, performance) don't seem to apply at first glance.
Because the program it's used in is written in C too, as is most software that runs on Unix-like systems. It uses and depends on another C library (PCRE). The P2V system has to fit on a small bootable ISO, so minimising code size and dependencies is an overriding concern. Also it was written in 2014.
My thoughts exactly. I love using expect, but why would I write a C program when I quick and simple TCL script (expect is build with TCL and is threaded and easy to make thread-safe scripts).
There are also expect clones in Python and Perl (probably others, but I know and have used those both) if TCL is an issue for you.
This looks nice, but I don't see if as very useful.
One potential use case could be in creating bindings for other languages that do not have an expect like module. Since it reportedly has a "saner interface than libexpect", it might be less hassle creating FFI bindings to mini-expect.
I won't lie, I've used the original expect just because I needed to force a program to run in a pty. It turns out that script(1) will also do this though.
It's LGPLv2+ which doesn't restrict your use in any way — you can combine it with proprietary code, ship it in closed source products etc — but does mean that you must contribute changes (to this library code only) back rather than being able to steal them from the commons for your proprietary benefit.
It's a cool unnamed product you work on, but being proprietary means that it's useless for any project I've ever worked on.
Did you actually think that anyone could possibly sympathize with a complaint about the intolerability of reciprocity?
Whatever product you're working on, if it can't include any gpl code, then it means they give you money instead. Do you hear yourself? "Boo hoo I can't take without giving" ?
Or are you claiming that you have only ever worked on MIT projects?
No license is going to be suitable for everyone. You might think BSD, MIT, WTFPL are the most liberal licenses but they are not suitable for me. If I am invested in an open source software enough to contribute code to it then I want that when a greedy company takes that software and improves it and redistributes it they are also forced to release the source code benefitting everyone. BSD, MIT, WTFPL can't do that but GPL can. No license is a silver bullet.
So for everyone as ignorant as myself, I guess it's referring to this[1]:
> Expect is a tool for automating interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc.
[1] https://core.tcl-lang.org/expect/index