Where the Tool Command Language really shines is this, commanding tools. TCL is criminally underrated for that use case.
Expect – Linux tool for automating interactive programs
81–90 of 92 posts
Re: Expect – Linux tool for automating interactive programs
#82[deleted]
Re: Expect – Linux tool for automating interactive programs
#83Where the Tool Command Language really shines is this, commanding tools. TCL is criminally underrated for that use case.
MacPorts is a noteworthy project that seems to use Tcl in its sweet spot.
Re: Expect – Linux tool for automating interactive programs
#84I use pexpect frequently for automating serial-port communications. It’s very useful for implementing test/flashing automation that needs some kind of a serial-port step (such as asking u-boot to run a few commands).
I do something very similar, how do you deal with random serial port data loss (dropped bytes)? Maybe it is specific to my environment, but I get mangled commands about 1% of time, which really sucks for automated workflows. I mostly countered this by writing commands to a tmp file, verifying md5sum and then executing the file on the device side.
Across a large enough sample set, I definitely see occasional serial errors (although they're rare).
For me, I detect them by checking the exit-code on each command that I run, and also by looking for expected output in response to the commands.
Corrective action is usually a full-stage retry.
Re: Expect – Linux tool for automating interactive programs
#85Earlier quoted context omitted.
Arguably, Tcl can do GUIs much easily and can integrate C less awkwardly than Perl. Both have their use cases, at any rate, and more people should use Tcl, Perl and any version of Expect. Nowadays it falls into the category of tools that were once somewhat used, but now are obscure, like fold/fmt, nl, comm and pr.
>> Arguably, Tcl can do GUIs much easily and can integrate C less awkwardly than Perl. We used Perl/Tk for GUIs on that old system. It brimgs the ease of Tk GUIs to Perl: https://metacpan.org/dist/Tk/view/pod/UserGuide.pod >> Nowadays it falls into the category of tools that were once somewhat used, but now are obscure To be sure, but a lot of it still works without changes!
Perl/Tk has always been a red headed stepchild since it is a fork attempting to implement a C API that doesn't require Tcl to be linked. Because of that, it has long missed out on significant improvements to Tk over the years. Python Tkinter avoids that by just wrapping around a Tcl interpreter.
Re: Expect – Linux tool for automating interactive programs
#86Expect is such a great tool for a specific class of problem. Decades ago I worked as a test engineer for a big hardware vendor. We had maybe a couple hundred raid controllers that we were testing and to address some issues we found, the supplier needed us to change a bunch of configuration variables that were only accessible via a text menu system over a serial connection to these devices. After painful manual reconf…
[deleted]
Re: Expect – Linux tool for automating interactive programs
#87claude.ai just suggested this as a tool for automating a workflow that involves ssh'ing into another machine and running some commands as sudo. I'm surprised I've never heard of this tool before. It works great for this scenario and the script can be used a reference to go in manually.
What the hell. If the device you are logging into supports sudo then it probably supports bash or python too. In that case a better solution is to create a script on the target device and then call that script over ssh, using key-based authentication. You do not need expect. Expect is mainly used on devices with a rigid terminal UI that do not support scripting and require interactive password authentication.
That's definitely do-able, but I didn't want to do that because it adds a level of indirection. When I put my relevant commands in a script, I have to start thinking about what directory it's in and how that affects its operations. I also have to think about how to handle errors for failures of the various commands, and I can only handle those errors on the target machine. If I'd doing expect and a command has an error, I can handle it on my local machine which might have more info (maybe I can set it up to switch to a backup machine or something). Are these solvable problems? Sure, for me it's a matter of taste.
Also, your comment would read almost identically and perhaps even better without the first three words.
Re: Expect – Linux tool for automating interactive programs
#88Linux tool? Hate when everything Unix automatically gets categorized as Linux. Have used Expect for many years for many use cases from automating servers to networking use cases as well.
For example, expect(1) is described in the 1989 Don Libes book "Life with UNIX". Libes is the author of Expect. A title such as "Life with Linux" would probably have made little sense at the time.
Re: Expect – Linux tool for automating interactive programs
#89I find I am able to duplicate basic expect functionality by running tmux on the server and using tmux commands, namely tmux send and tmux capture.
Re: Expect – Linux tool for automating interactive programs
#90Linux tool? Hate when everything Unix automatically gets categorized as Linux. Have used Expect for many years for many use cases from automating servers to networking use cases as well.
For example, expect(1) is described in the 1989 Don Libes book "Life with UNIX". Libes is the author of Expect. A title such as "Life with Linux" would probably have made little sense at the time.
Correction: I went back and looked at the book and it does not mention expect. According to Wikipedia expect was first released the following year, in 1990. Apologies for the inadvertence.
Nevethless I think it is safe to say that expect was not written using or for Linux as Linux was not released until 1991.