The Linux expect command takes script writing to an entirely new level. Instead of automating processes, it automates running and responding to other scripts. In other words, you can write a script that asks how you are and then create an expect script that both runs it and tells it that you’re ok.
Here’s the bash script:
#!/bin/bash echo "How are you doing?" read ans
Here’s the expect script that provides the response to the query:
#!/usr/bin/expect set timeout -1 spawn ./ask # ask is name of script to be run expect "How are you doing?r" send -- "okr" expect eof
When you run the script, you should see this:
$ ./ask.exp spawn ./ask How are you doing? ok
Note that you would just invoke the expect script (ask.exp). The script itself answers the question for you.
The first line of the expect script (ask.exp) shown above disables a possible timeout. The second kicks off the script that will be asking for a response using spawn.
Note that the expected prompts have to match what is asked precisely. Even “How are you doing?” and “How are you doing? “ (note the extra space between the question mark and quotation mark) aren’t matches. And, if your script includes the command echo -n “How are you doing? “, the expect script needs to use expect “How are you doing? “, not expect “How are you doing? n”.
Here’s a slightly more complicated example. If a script that you use asks you to identify a directory that you want to back up in the form of a compressed tar file, it might look like this:
#!/bin/bash echo -n "Directory> " read dir tar -czf $dir.tar.gz ~/$dir
The corresponding expect script that runs the script and provides the name of the directory to be backed up might look like this:
#!/usr/bin/expect set timeout -1 spawn ./dirbackup expect "Directory> " send -- "PNGsr" expect eof
Obviously, this script isn’t particularly useful because it backs up just one particular directory, and you could do that more easily by just running the tar command. For more complex interactions, this would not be the case.
When to use expect
In general, the only time you would likely want to use expect is with scripts that ask way more questions than you feel like answering or that you want to run when you’re not around. For example, a script used to install some particular application might ask six critical questions and then require that you reply “y” many more times before proceeding with the install. There may be times, too, that you might need to install an application on 32 servers or simply want or have it installed overnight while no one is using them. You could automate that process by asking expect to run the script and provide all of the answers for you.
Here’s an example, though the script in this case isn’t really doing anything with the answers that it collects.
The install script:
#!/bin/bash echo -n "Location of installation file> " read dir echo -n "Which components to you wish to install [all,core,enduser]> " read ans echo -n "Is your license file up-to-date? [Y,n]> " read ans echo -n "Should user responses be logged? [Y,n]> " read ans echo -n "Enter Y if ready to begin install [Y,n]> " read ans
The expect script that might run this script will look similar:
#!/usr/bin/expect set timeout -1 spawn ./installapp expect "Location of installation file> " send "/var/installsr" expect "Which components to you wish to install \[all,core,enduser\]> " send "allr" expect "Is your license file up-to-date? \[Y,n\]> " send "Yr" expect "Should user responses be logged? \[Y,n\]> " send "Yr" expect "Enter Y if ready to begin install \[Y,n\]> " send "Yr" expect eof
The install script would, of course, need to use the collected answers and run the proper commands to install the required software. The trick here is to capture the questions that will be asked and send the right answers to each one.
Note that the \ sequences used in this expect script are required to escape the square brackets.
Autoexpect
There is a way to make preparing expect scripts a lot easier. That is, you can provide your script as an argument to the autoexpect command and it will create the expect script for you. You use a command like autoexpect ./installapp and it will build an expect script with the answers that you provide:
$ autoexpect ./installapp autoexpect started, file is script.exp Location of installation file> /var/installs Which components to you wish to install [all,core,enduser]> all Is your license file up-to-date? [Y,n]> Y Should user responses be logged? [Y,n]> Y Enter Y if ready to begin install [Y,n]> Y autoexpect done, file is script.exp
The resultant script.exp file will then include an explanation that it was created with autoexpect and will include the responses you provided. Here’s what we’d see in the file after the interactions shown above:
$ tail -18 script.exp
set timeout -1 spawn ./ask04 match_max 100000 expect -exact "Location of installation file> " send -- "/var/installsr" expect -exact "/var/installsr Which components to you wish to install [all,core,enduser]> " send -- "allr" expect -exact "allr Is your license file up-to-date? [Y,n]> " send -- "Yr" expect -exact "Yr Should user responses be logged? [Y,n]> " send -- "Yr" expect -exact "Yr Enter Y if ready to begin install [Y,n]> " send -- "Yr" expect eof
The autoexpect tool prepares the script for non-interactively running an installation. You can then do installs without having to supply the details or just schedule them to run on their own.
Wrap-Up
The expect command is handy for running scripts that require a long series of answers and allows you to run them in an un-manned fashion while autoexpect makes it easy to create expect scripts without stressing out over the syntactical details.
Copyright © 2021 IDG Communications, Inc.
