The document outlines a webinar session led by Kellyn Gorman, an Azure Data Platform Architect, focused on teaching the basics of Linux scripting. It covers key practices for writing scripts, including structure, debugging, and the use of functions, alongside tips for enhancing usability and maintaining best practices. Additionally, it provides resources for further learning and emphasizes community involvement in SQL and data platform technologies.

1. Empowering the SQL
Server Professional
with Linux Scripting
Kellyn Gorman,
Azure Data Platform Architect
Microsoft

2. Please silence
cell phones

3. everything PASS
has to offer
Free online
webinar events
Free 1-day local
training events
Local user groups
around the world
Online special
interest user groups
Business analytics
training
Get involved
Free Online Resources
Newsletters
PASS.org
Explore

4. Kellyn Gorman
Azure Data Platform
Architect, Microsoft
Azure Data Platform Architect
Kellyn has been with Microsoft for over a year
now working in the Analytics and AI team in
Higher Education but spends a percentage of
her time migrating large Oracle environments
over to Azure bare metal.
Blogger, Author, Speaker
Kellyn writes on two of the top 50 database
blogs in the world, known for Oracle and
Microsoft technical content, has written five
books, including one on Diversity and
Inclusion. She mentors, sponsors and speaks
in both the Oracle and Microsoft communities
as part of giving back to the community.
President, Denver SQL Server User
Group
Kellyn has been the president for over two
years now, continuing to support this
incredible user group while on the road in her
RV, traveling the US.
@DBAKevlar
https://www.linkedin.com/in/kellyngorman/
Kellyn.Gorman@Microsoft.com

6. What This Session Is….
• Teach you the basics around Linux, (aka bash) scripting.
• Play along if you want, just need a Linux machine to log into or
log onto.
• Scripts and slides will be available post the session on
https://github.com/Dbakevlar/Summit2019
• This includes a VI(M) Cheatsheet!

7. One Way: Azure Cloud Shell
https://docs.microsoft.com/en-us/azure/cloud-shell/overview
Supports both BASH and PowerShell
Can be used with persistent cloud storage

8. Choose Wisely How You Author Your
Scripts
Scripts should be easy to:
• Read
• Edit
• Execute
8

9. Even if You Don’t
Already Know
How to BASH…
1. The following tips are good to
consider in any scripting language
when available
2. Are good practice to be a good
coding team member
3. May save your life some day, (or
keep you from getting killed by your
team members… )
9

10. Writing a Script Should be…
Like writing a paper. It should include the following:
• An Introduction
• A Body
• A Conclusion
10

11. The Introduction
11

12. Set the Shell to Use
Find out which shell is in use:
which bash
Setting it in your script is done at the very first line of your script:
#!/bin/bash
OR
#!/bin/sh -C Shell
#!/bin/ksh -Korn Shell
For many Linux machines, there may be more than one:

13. What Happens If You Don’t?
./<script name>/sh <arg1> <arg2>
Without shell set in script:
/bin/bash ./<script name>/sh <arg1> <arg2>
The script must state what shell is to be used with the script EVERY TIME.
Normal Execution with the shell set in the script:

14. Exit When Mistakes are Made
Added at the top of the script under the designation of shell
set –e
set –o errexit
Saves from clean up, easier to recover from.

15. Also Exit if Undeclared Variables, etc.
Require declarations to be set completely or the script exits:
set -o nounset
OR
set –u
set -euo pipefail
Blank answers for variables, (arguments) can leave a script
to execute incorrectly or worse.

16. Add Debugging to Your Script
Want to know what went wrong?
#!/bin/bash
set -vnx
Arguments, (any or all) to be used:
Argument What it Does
-v Verbose mode- shows all lines as they are parsed by the
execution.
-n For syntax checking. The script doesn’t actually execute.
-x Shell tracing mode- will step through each step and report
any errors

17. Set up Alias’ and Environment Variables
Create .profile with a unique extension, (.profile_sql19, .profile_net) to support
unique applications.
This cuts down on significant variable setting and coding, requiring only one
location to update/manage.
Update the .bashrc with global alias’ and environment
variables that support anything that is used by the login
regularly.

18. Write a Header for your Script
The # sign can help create a header and signal BASH that it’s for
informational purposes only:
####################################################
# Title: summit_demo.sh #
# Purpose: Summit Demo script for Linux #
# Author: Kellyn Gorman #
# Notes: Script will need three arguments. #
####################################################

19. Four Choices in Passing Environment
Variables
1. Declaration hard-coded in script
2. Passed as part of execution command for script
3. Interactively read as part of script execution
4. Dynamically generated from other values in script
19

20. Choose Wisely
20
Variable Type Pro Con
Hard-coded No typos Static, no interaction
Passed during
execution
More interactive and code
is more dynamic, great for
automation
Can suffer typos, no hints
of values required
Interactively read as
part of execution
Very interactive and can be
prompted with
hints/options
Requires interaction and
not made for scheduling
or automation
Dynamically
generated from
other values
Dynamically happens,
requires no/little input
from users. Excellent for
automation
Little/no control over
values, dependent on
values passed or existing
from sources.

21. Start of our Script
21
#!/bin/bash
#############################################
# Script Name: summit_demo_int.sh #
# Author: Kellyn Gorman #
# Usage: For Linux Scripting Demo #
# Notes: Hard coded values to begin #
#############################################
export dir_name = summitdir
export file_name = summit.lst
export log_name = summit.log
summit_demo_int.sh

22. How to use Variables Once Declared in
a Script
dir_name becomes $dir_name
file_name becomes $file_name
…and so on…
Any variables in the .bashrc or .profile can be used in scripts
and if reused often, should be considered set in these files.
22

23. Move from Hard Coding to Passing
Variables at the Execution
Changed at the Introduction of the script
Makes script more robust and flexible
Makes script reusable
Can be done multiple ways
• Set at session/logon
• Set as part of script execution
23

24. Start of our Script
24
#!/bin/bash
#############################################
#############################################
export dir_name = <generic dir path>
export file_name = <static file name>
export log_name = <static log name>
Export the summitdir variable and run the summit_demo_arg.sh:
export dir_name=summitdir
./summit_demo_arg.sh
summit_demo_arg.sh

25. Update the Script to Interactive Values
export dir_name = <dir path>
export file_name = <generic_file_name>
export log_name = <generic_log_name>
To execute, we would change to execution path ./<script name> $1
Export the environment variables as part of a profile or part
of your .bashrc OR add to the script/session. This is one
more way to make the script easier to use.
25

26. Start of our Script
26
#!/bin/bash
export acro=$1
#############################################
#############################################
# Directory is already set, just need to set the file/log name
# Note, the files are unique to the script, but generic to the
environment session:
export dir_name=${dir_name}/${acro}<dir_name>
export log_name = ${dir_name}/${acro}<log_name>
summit_demo_val.sh

27. Pass Dynamic Values into our Script,
Step 1
usage() { echo "Usage: $0 -f <filename> -l
<logname>" 1>&2; exit 1; }
declare file_name=""
declare log_name=""
27

28. Pass Dynamic Values into our Script,
Step 2
# Initialize parameters specified from command line
while getopts ":f:l:" arg; do
case "${arg}" in
f)
filename=${OPTARG}
;;
l)
logname=${OPTARG}
;;
esac
Done
shift $((OPTIND-1))
28

29. Pass Dynamic Values into our Script,
Step 3
if [[ -z "$filename" ]]; then
echo “Type in the name of your file:"
read filename
[[ "${filename:?}" ]]
fi
if [[ -z "$logname" ]]; then
echo “Type in your logname:”
read logname
[[ "${logname:?}" ]]
fi
29

30. Script has changed on how we setup our
introduction, but body stays the same….
Save your file, (“Esc, :q!” in VIM/VI, which is listed in your VI(M)
cheat sheet)
30 summit_demo_dyn.sh

31. Test your Environment Variables
Use the scripts you’ve created
Make sure they are executable:
chmod 744 *.sh
Run each of the scripts
Test the variables, are they set?
echo $<variable name>
Do this for each script for each variable…
31

32. The Body
32

33. The Body of the Script
This is where the code will perform the work as part of the main purpose of
the script.
As when writing a paper, this will be the largest section of your
script.
Start simple
Add debugging and error exit options as you build out your
body.
*Consider building a script as functions- easier to manage and test.
33

34. Don’t Leave Others in the Dark
Write in ideas for enhancements
Help explain the logic
Use the # sign to signal your script that it’s a comment.
# This step builds out the database logical objects.
# If the variables aren’t entered, the script will exit.
Comments in your scripts

35. Goal of Script
• Create a directory, (mkdir)
• Create an empty file, (touch)
• Confirm the creation of the directory with a list, (ls) and write
to a log file, ( >)
• Confirm the creation of the file with a list, (ls) and append to a
log file, (>>)
35

36. Create the Body, (Post the Variables)
36
export dir_name = summitdir
export file_name = ${summitdir}/summit.lst
export log_name = ${dir_name}/summit.log
# Create new directory
mkdir ./${summitdir}
# Create empty file
touch ./${file_name}
# Verify that directory and file exist
ls ./${summitdir} > $log_name
ls ./${file_name} >> $log_name

37. Don’t Make Users Guess
If there is a step that requires interaction between your script and
the user, make it clear what is required to promote success:
This can be done using the ECHO command and placing the
statement inside quotes.
echo “Please enter the name of the user:”
37

38. Don’t throw away your other scripts
Just as with .Net, Java, Perl, etc., you can run PowerShell
scripts from BASH:
pwsh <script name>
You worked hard on scripts or an existing example already
exists. Don’t recreate the wheel and consider reusing them,
calling them from your BASH script.

39. Build Out Functions
• Functions allow you to group commands and execute
them as part of a function name.
• Write in any order, execute in the order you want
• Place execution at the end of the script to make it easy
for managing, testing and understanding steps in a script
39

40. Example of Function
# Function Bodies:
function quit {
exit
}
function hello {
echo Hello!
}
# Execute Function:
hello
quit
40

41. # First function touch files
function touch_func {
touch ${file}
touch ${log_file}
}
# Second function to Verify that directory and file exist
function write_log_func {
pwd ${home}/${dir_name} > $log_file
ls -ltr ${file} >> $log_file
ls -ltr ${log_file} >> $log_file
}
41
Our Functions

42. Function for Last Step- Commented
Out!
function clean_func {
rm -rf $dir_name/*
rmdir $dir_name
}
Be careful with rm –rf!!
42

43. The Conclusion
43

44. If Using Functions
Execute Functions and then-
• Add any last logging steps
• Clean up any files
• Email log files or notifications
44

45. Complete our Script
# Conclusion
# Execute Functions and clean up
touch_func
write_log_func
#clean_func # function is commented out to
begin!
echo “Script has completed” >> $log_name
45

46. Always do Clean Up and Notify
Completion
• Remove any files that were created for script.
• Parse log files for success or errors.
• Report on success or errors.
• Notify the script has finished, successfully or even if it
hasn’t.
46

47. Executing Functions
Functions are executed as part of the conclusion and…
• Makes it easier to test and work with sections of scripts.
• Check out the full script: summit_demo_func.sh
• Run Script with CLEAN function commented out!
47

48. Test out the Scripts!
• Note the differences
• Note how more commands would be built in.
• Notice logging and how commands can be used as well as
checks.
• More advance utilities/commands: AWK, GREP, SED to do
advanced filtering and searching.
• Use email utilities like sendmail for notifications, alerting
48

49. Summary
• Learn Vi/Vim, Nano or another editor to make it easy to write
scripts in the Linux terminal.
• Use best practices from the beginning so as scripts mature,
already easy for others to read, manage and use.
• Use dynamic values to make code reusable
• Use functions to make easier to manage and test scripts
• Use exit codes for variables and errors to keep scripts from
running without the right information.
49

50. If You Want to Learn More:
Blog Posts, Writing Shell Scripts, Parts 1-4
PASS Summit Session, Empowering the SQL Server
Professional with Linux Scripting- Thursday, Nov. 7th,
1:30pm, RM 611-614
Web Tutorials, Linux Shell Scripting
Edx Class, Linux Command Line Basics
Linux Scripting Class, Linux Tutorials
50

51. Session
Evaluations
Submit by 5pm Friday,
November 15th to
win prizes.
Download the GuideBook App
and search: PASS Summit 2019
Follow the QR code link on session
signage
Go to PASSsummit.com
3 W A Y S T O A C C E S S

52. Thank You
Speaker name
@DBAkevlar
dbakevlar@gmail.com