This article is NOT a continuation of the previous article. The topics covered in this article won’t be used in our folder creation script as the features covered are not required or can’t be appropriately used. We will use a different script instead. This article is a continuation of the Shell scripting series though.
Why automate?
Most of the times we or someone else will be running the desired script. However there is one major drawback with this. It assumes that there is ‘someone’ who can run the script and they have access to the computer that the script is supposed to run on. This is not always a given.
The above approach also has the problem of efficiency. If the script is to be run periodically or at regular intervals it can get very inefficient and is likely to affect the workflows of the organisation.
Automation solves these problems for us by allowing scripts to run by themselves.
How to automate?
There are 2 options that we will look at in this article:
- Expect utility
- Launch Daemons/Launch Agents
Expect utility
The expect
utility isn’t strictly an automation solution. It’s a tool that can answer stdout prompts from another script/program/application. Let us see how it works with an example.
The script below is asking a series of questions from the user and is expecting a response. The response is stored in a variable which is echo’d out. To make it interesting the last question is a choice based questions. Based on some random value the script will ask question ‘a’ or question ‘b’.
#!/bin/zsh
# Questions
# --------------------------------------------------
echo "1) What is your name?"
read -s NAME
echo $NAME
echo "2) What is your email address?"
read -s EMAIL
echo $EMAIL
echo "3) Could you tell me your company's website address?"
read -s WEBSITE
echo $WEBSITE
echo "4) Please provide your mobile number?"
read -s MOBILE
echo $MOBILE
# Choice
# --------------------------------------------------
if [[ $RANDOM -gt 90000 ]]; then
echo "Do you like option A?"
else
echo "Would you prefer option B?"
fi
read -s OPTION
echo $OPTION
Now if we just run the above script we would see prompts on stdout for the different questions and simply answer them. But what if this script is going to be called by another script? That is where the expect
utility comes in. Let us have a look at out script and then analyse it
#!/bin/zsh
#!/usr/bin/expect
#Variables
ANS1="Arun"
ANS2="arun@amaranthine.co.in"
ARG1=$1
export ANS1
export ANS2
export ARG1
/usr/bin/expect << "EOF"
set myValue1 $env(ANS1);
set myValue2 $env(ANS2);
set arg1 $env(ARG1);
spawn /Users/arunpatwardhan/Developer/questions.zsh
expect "1) What is your name?\r"
send -- "$myValue1\r"
expect "2) What is your email address?"
send -- "$myValue2\r"
expect "3) Could you tell me your company website address?"
send -- "www.amaranthine.in\r"
expect "4) Please provide your mobile number?"
send -- "$arg1\r"
expect {
"Do you like option A?" { send -- "Of course!\r" }
"Would you prefer option B?" { send -- "Definitely!\r" }
}
expect eof
EOF
Let us analyse this file line by line.
The first line is our interpreter declaration. The second line is where we specify which expect we will be using.
#!/bin/zsh
#!/usr/bin/expect
Next we declare some variables. We will use them in our expect utility soon.
#Variables
ANS1="Arun"
ANS2="arun@amaranthine.co.in"
ARG1=$1
In order to use them in our utility we need to export these variables. We will then access them via the environment.
export ANS1
export ANS2
export ARG1
This is where we start writing our expect command. Notice that we are using the ‘here’ document that we learnt in the previous script. This allows use to send multiple expect commands to the expect utility.
/usr/bin/expect << "EOF"
The first thing that we do is create variables for the expect utility from the variables that we already have.
set myValue1 $env(ANS1);
set myValue2 $env(ANS2);
set arg1 $env(ARG1);
Then we use the spawn
command to start the script whose questions we wish to answer.
spawn /Users/arunpatwardhan/Developer/questions.zsh
Next we tell the expect utility to ‘expect’ a question. We specify the question to expect in the string after the expect
command.
expect "1) What is your name?\r"
Once the expectation has been met, we send out our response to the question using the send
command.
send -- "$myValue1\r"
We can answer the rest of the questions the same way. We can use variables to pass in data or directly write our answers in there.
In case of a choice we write an expect block command with the help of braces.
expect {
"Do you like option A?" { send -- "Of course!\r" }
"Would you prefer option B?" { send -- "Definitely!\r" }
}
Finally we end with an eof
being passed to expect.
expect eof
The last EOF is for the ‘here’ document.
EOF
That’s it! It’s that simple to write expect scripts. Note that there are more commands available for the expect utility. I would strongly recommend going through the man page for details about expect.
man expect
There is also a utility called autoexpect
that builds the expect script for you. As of this article (tested on macOS 12.6) it is not installed by default.
One last thing I would like to mention. The expect utility should ideally be used in a larger script which is invoking other scripts. It is not meant to replace human interaction. Use caution when invoking scripts/binaries/tools that you cannot read as you are not fully aware of everything that is done by these scripts.
Launch Daemons/Launch Agents
The other and option is to use launch daemons/launch agents. I will be referring to them as daemons through the rest of this article unless something specific has to be mentioned.
Daemons solve a different problem as compared to the expect utility.
The expect utility allows for a script/binary/tool/program to complete execution by answering questions expected from a human.
Daemons on the other hand allow us to schedule and automatically run scripts and custom intervals. These are background processes that are started on specific events. Daemons and agents are exactly the same, but they have some key differences:
Launch Daemons | Launch Agents |
---|---|
These are owned by the system | These are owned by the currently logged in user |
Start as soon as the system boots up | Starts only after the user logs in. Stops as soon as the user logs out |
Is system wide | Can apply to all user accounts or to a specific user account |
These are some of the points that you have to keep in mind while deciding whether to create a daemon or an agent. The process for creating them is exactly the same. It is plist file that provides all the information that is necessary for the system to schedule and run the processes.
I will be talking about launch daemons and agents as well as plist files in separate articles at a later point in time.
Example
Let us look at how to create a daemon with the help of an example.
We would like to show an informational popup that appears as soon as the user logs in and at 5 minutes interval. We would also like to show a notification of the same.
Now this could also be achieved using other approaches but it gives us an opportunity to explore how to create agents. Also the scheduling is chosen so that we can see how it is done. It is not strictly required for this situation.
So why have we decided to create it as an agent?
The main reason is because it is to run only after the user logs in. Something that a Launch Agent is perfectly suited for.
We also want this to run for every user account on the computer. So this will need to be installed in the /Library
folder. Specifically:
/Library/LaunchAgents/
Now that we have decided how and where let us focus first on the script that we plan to run.
#!/bin/zsh
/usr/bin/osascript << EOF
display notification "By using this computer you agree to terms and conditions of use set down by the company." \
with title "Terms & Conditions" \
subtitle "Acknowledge" \
sound name "Alert"
set theAlertText to "Terms and conditions of use"
set theAlertMessage to "By using this computer you agree to terms and conditions of use set down by the company."
display alert theAlertText \
message theAlertMessage \
as informational \
buttons {"Accept"} default button "Accept"
EOF
The script simply uses the osascript
command to run a few AppleScript commands. These commands show a notification as well as an alert message to the user. Let us place this script in the /Library/Scripts/ folder. This will make it easily accessible.
Next we will focus on creating the launch agent plist. Let us first list out the items we will need to put in the plist.
Key | Description |
---|---|
Label | This is the name of our Launch Agent |
ProgramArguments | This is the action to be performed. In our case the action is to invoke the script. |
StartInterval | This is the time interval after which the program arguments must be executed. |
RunAtLoad | This is a flag that indicates that the agent must be run as soon as it is loaded. |
Armed with this information we will go ahead and create our plist. There are several tools available for this:
- Xcode
- TextEdit
defaults
command- Third party tools like CodeRunner
We will use the defaults command for this. It is a built in command that allows us to work with plist files. Here is a little script that creates our plist.
#!/bin/zsh
defaults write ~/Desktop/in.amaranthine.welcomeMessage.plist Label -string "in.amaranthine.welcomeMessage"
defaults write ~/Desktop/in.amaranthine.welcomeMessage.plist ProgramArguments -array-add "/bin/zsh" "/Library/Scripts/welcome.zsh"
defaults write ~/Desktop/in.amaranthine.welcomeMessage.plist RunAtLoad -boolean true
defaults write ~/Desktop/in.amaranthine.welcomeMessage.plist StartInterval -integer 300
In the script, the defaults command is writing several key value pairs into a plist file at the specified path. Notice the key names: Label, ProgramArguments, RunAtLoad, StartInterval. These are the values we need to specify. The above commands need not be written in a specific sequence as they are being written to an XML file.
The resulting plist file should look like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>in.amaranthine.welcomeMessage</string>
<key>ProgramArguments</key>
<array>
<string>/bin/zsh</string>
<string>/Library/Scripts/welcome.zsh</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StartInterval</key>
<integer>300</integer>
</dict>
</plist>
Lets explore the different parts of this plist file. It contains a dictionary with several key value pairs.
<key>Label</key>
<string>in.amaranthine.welcomeMessage</string>
The first key value pair we encounter is ‘Label’. This is the name of our agent.
<key>ProgramArguments</key>
<array>
<string>/bin/zsh</string>
<string>/Library/Scripts/welcome.zsh</string>
</array>
The next key value pair is extremely important. It is telling our agent the task that needs to be performed. In this case use the zsh shell to run the welcome.zsh script. This is the same as running the following command in terminal:
/bin/zsh /Library/Scripts/welcome.zsh
<key>RunAtLoad</key>
<true/>
The second key value pair indicates that the agent must run as soon as it is loaded and not only when the user logs in. This is not strictly required but is very handy when we try to test our agent.
<key>StartInterval</key>
<integer>300</integer>
The last key value pair will schedule the agent to run at an interval of 5 minutes or 300 seconds.
You can check if the plist if properly formatted using the command:
plutil -lint /path/to/plist
Also, if you try to open the plist file in an editor it is likely that the formatting may not appear correctly. Run the following command to make it readable:
plutil -convert xml1 /path/to/plist
This does not affect the plist file in any way. So it is safe to perform.
The next bit is to place the file in correct location. Copy the plist file to the path:
/Library/LaunchAgents/
Next we will look at loading the agent
While the agent will be loaded automatically every time the user logs in. However, we would like to test the results immediately. We will use the launchctl
command to load the agent.
launchctl bootstrap gui/501 /Library/LaunchAgents/in.amaranthine.welcomeMessage.plist
Let us explore the launchctl
command.
The bootstrap option informs the system that an agent is being loaded.
The next bit tells launchctl that its for gui user 501. We can get the user number using the command id -u
.
This is followed by the path to the plist file.
Run this command.
To find out if the launch agent has loaded correctly we will use the list option on launchctl to list out all the current agents.
launchctl list
To get more specific results:
launchctl list | grep "in.ama"
This will show a list of agents whose name starts with “in.ama”.
And that’s it. We have now scheduled the agent. If you have run the command to bootstrap the agent then you should see the popup appearing on the screen.
You should also see the notification:
If you wish to stop the agent run:
launchctl bootout gui/501 /Library/LaunchAgents/in.amaranthine.welcomeMessage.plist
It’s the same command as before. Except with the bootout option instead of the bootstrap.
NOTE: The agent will start running again the next time the user logs in.
Summary
As you can see there are several options available when it comes to automating scripts. This opens up more possibilities when it comes to performing management tasks on the device.
Video
Download
You can download the scripts from here: