Very handy tool. I use it to partially automate logins on a CLI tool that have 2FA. Expect hooks op (1Pass’ CLI) to send the password, then tells the program what method of 2FA I want to use (Okta push to my phone).
Expect – Linux tool for automating interactive programs
71–80 of 92 posts
Re: Expect – Linux tool for automating interactive programs
#72Very handy tool. I use it to partially automate logins on a CLI tool that have 2FA. Expect hooks op (1Pass’ CLI) to send the password, then tells the program what method of 2FA I want to use (Okta push to my phone).
Same here - fetch the password from mac's "security" command, and then select the 2fa method.
Re: Expect – Linux tool for automating interactive programs
#73Expect used to be one of the "big" tools at one point. O'Reilly books written about it and so on. But then it went to obscurity. Kind of strange.
It's a rare thing nowadays to find a terminal command that is interactive and doesn't provide alternative flags for batch processing.
Expect would still be useful for someone scripting a debugger (for example), but Tcl falls under the close to isoteric language nowadays and it takes less time to just repeat the commands in a readline capable interactive program than find just the right way to script it.
Last time I've tried to use expect was when I attempted to build a Tk frontend to the Haskell GHCi debugger (similar to the DDD application), but I got tripped up, from vague memory, on terminal ansi codes, and random lock ups I couldn't pinpoint.
Re: Expect – Linux tool for automating interactive programs
#74Earlier quoted context omitted.
Definitely, `sshpass` is the more better keyhole tool for this job. I picked it as the most common example I can imagine everyone going "ugh, I have to do this by hand again ?" at.
sshpass is a travesty of security. It has all the pitfalls of putting your front door key under your doormat. Except you're doing it in a world where everyone can materialize a unique key out of thin air, and you can always instantly tell your door which of those keys should or shouldn't be allowed to open it. sshpass is a curse, even calling it a crutch would be improper flattery. It's a dangerous cheat that accompl…
Yes this is the proper dogma, but you're missing the point.
Any automation around passwords is a crutch and a mistake. But sometimes it is necessary.
You don't always control the remote systems. The remote systems are not always capable of key-based auth. And sometimes the remote system is not of high concern so the "danger" is null.
sshpass makes a reasonable effort to do the best-possible thing under these less-than-ideal circumstances. The other options suck more.
My most recent use of sshpass is to collect reports from a vendor over sftp. I would have preferred to use https with BASIC auth, but in truth that has exactly the same problems as sshpass, and I have other hills to die on.
Re: Expect – Linux tool for automating interactive programs
#75I 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.
Serial is slow but typically very reliable. If you’re seeing random dropped bytes, I’d take a look at your wiring and PC interface UART which might be low quality. FTDI UARTs in particular are often counterfeit (the real ones are good).
Re: Expect – Linux tool for automating interactive programs
#76My go-to example for `expect` is password-based SSH. Since we're all enlightened beings these days who surely never use this anymore, there's no risk to it: #!/bin/bash expect -c " spawn ssh user@10.0.0.1 expect \"password:\" send \"12345\r\" interact " `interact` hands you back control to do whatever you want, but you don't actually need to do that. You can have `expect` run every command, fill out every field. The…
out of curiosity, why do you call the expect script in string form from a bash shebang, rather than make the script itself an expect script directly with an explicit expect shebang?
I have no technical reason, I just wanted to wrap it into a familiar context for people. People are I find less scared of "useful CLI tool I can script around" than "scripting language in its own right".
Re: Expect – Linux tool for automating interactive programs
#77My go-to example for `expect` is password-based SSH. Since we're all enlightened beings these days who surely never use this anymore, there's no risk to it: #!/bin/bash expect -c " spawn ssh user@10.0.0.1 expect \"password:\" send \"12345\r\" interact " `interact` hands you back control to do whatever you want, but you don't actually need to do that. You can have `expect` run every command, fill out every field. The…
You forgot all the other prompts that ssh might produce before the password prompt (e.g. add new host to known hosts yes/no). There are more possible prompts than most people realize.
You can skip the new host prompt with ssh -o options.
Re: Expect – Linux tool for automating interactive programs
#78Expect used to be one of the "big" tools at one point. O'Reilly books written about it and so on. But then it went to obscurity. Kind of strange.
It's a rare thing nowadays to find a terminal command that is interactive and doesn't provide alternative flags for batch processing. Expect would still be useful for someone scripting a debugger (for example), but Tcl falls under the close to isoteric language nowadays and it takes less time to just repeat the commands in a readline capable interactive program than find just the right way to script it. Last time I'v…
Some tools like ssh and gpg go out of their way to prevent easy use via command line flags. They often have a good reason for doing this, but there are also sometimes good reasons where this type of protection causes problems. Since the implementers won’t budge on their stance, you need workarounds like expect.
Re: Expect – Linux tool for automating interactive programs
#79claude.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.
Re: Expect – Linux tool for automating interactive programs
#80Expect helped launch my early career in programming.
Automating tedious tasks as a network engineer and sysadmin motivated me to learn proper software development. If gluing together TCL/tk scripts could make my life easier, imagine what larger programs would do.
The good days.