Briefing Document: Fundamentals of Shell Scripting
Date: [Current Date] Subject: Introduction to Shell Scripting for Linux Environments Sources:
•  "FAQ ShellScripting includes variables" (Adrianna Holden-Gouveia, YouTube)
•  "Introduction to Shellscripting" (Text resource)
•  "TLDR CIS117 Week 8" (Adrianna Holden-Gouveia, YouTube)

--------------------------------------------------------------------------------
1. Executive Summary
This briefing document provides an overview of shell scripting, a foundational skill for Linux users. It covers the definition, purpose, creation, execution, and essential syntax of shell scripts, emphasizing best practices and common pitfalls. The information is drawn from a series of educational resources designed to equip learners with the knowledge to automate tasks, solve problems, and manage their Linux systems more effectively.
2. What is a Shell Script?
• A shell script is a small program consisting of a text file with one command per line.
• It is often referred to as "shell scripting" or "bash scripting".
• The primary goal is to automate repetitive tasks and repeated activities.
• Scripts help in "figuring out a puzzle and keeping the solution for that puzzle" for future use.
• They ensure consistency by documenting commands, preventing omissions.
• Shell scripts are useful for complicated tasks that are not performed often, eliminating the need to re-figure them out.
• They can also be used for troubleshooting basics on servers and networks by establishing baselines for comparison (e.g., comparing network packets over time).
3. Core Components and Syntax
• Shebang Line:
    ◦ The first line of a script that tells the system which interpreter to use for execution.
    ◦ It begins with #! (hashtag and exclamation point) followed by the path to the interpreter (e.g., #!/bin/sh or #!/bin/bash).
    ◦ While not strictly required for a script to run, it is considered good practice for clarity.
• Comments:
    ◦ Lines beginning with a hashtag (#) are treated as comments and are ignored during execution.
    ◦ It is good practice to include a comment at the top of the script detailing its function, the author's name, and the date.
• echo Command:
    ◦ Used to print text or variable values to the command line.
• read Command:
    ◦ Used to accept user input during script execution.
    ◦ It pauses the script, waits for input, and stores it in a specified variable.
• Variables:
    ◦ Shell scripting utilizes untyped variables, meaning their type (e.g., int, character) does not need to be declared.
    ◦ Variables are not declared at the top of the script.
    ◦ To use or expand a variable's value, precede its name with a dollar sign ($) (e.g., echo $answer).
4. Script Creation, Permissions, and Execution
• File Naming:
    ◦ It is highly recommended to add a .sh file extension (e.g., river.sh) to indicate that it is a shell script, even though Linux does not strictly require file extensions like Windows.
• Editing:
    ◦ Scripts are created and modified using a text editor such as vi or VIM.
• Permissions:
    ◦ A newly created file in Linux is not executable by default.
    ◦ Execute permission must be explicitly granted using the chmod command. An FAQ video provides a demonstration of this process.
• Running a Script:
    ◦ To execute a script, you generally need to provide the path to the script (e.g., ./river.sh for a script in the current directory).
    ◦ A common mistake is not correctly pointing to the script's location.
5. Handling Text and Quotes
The type of quotes used with commands like echo significantly impacts variable expansion:
• Plain (No Quotes):
    ◦ echo hello simply prints the text literally.
• Semi-Opaque (Double Quotes):
    ◦ echo "hello $name" expands variables within the quotes.
• Opaque (Single Quotes):
    ◦ echo 'hello $name' shows exactly what is in the quotes, preventing variable expansion.
• Backticks (`):
    ◦ Used to execute a command within a script and use its output.
    ◦ The results can be stored in temporary variables (e.g., set \date``).
    ◦ Crucially, a backtick is distinct from a single quote. On an American keyboard, the backtick is typically located above the Tab key, next to the tilde (~).
6. Best Practices and Troubleshooting
• Test Commands First: Always test individual commands at the command prompt before integrating them into a script. This becomes more intuitive with experience.
• Sequence for a Successful Script:
    1. Test commands at the command prompt.
    2. Create and edit the file using a text editor (e.g., VIM).
    3. Begin the script with a shebang line (e.g., #!/bin/bash).
    4. Add a comment at the top detailing the script's function, your name, and the date.
    5. Save the file.
    6. Change permissions to make it executable.
    7. Test the script thoroughly!
    8. Rinse and repeat for modifications and debugging.
• Thorough Testing is Critical:
    ◦ "PLEASE TEST YOUR CODE".
    ◦ Never use or submit untested code.
    ◦ Be prepared to prove code has been tested (e.g., with screenshots or by copy-pasting code). Avoid vague explanations like "I think it works" or "it should have worked".
• Common Mistakes:
    ◦ Not making the script executable by default.
    ◦ Not correctly providing the path to the script when running it.
7. Suggested Activities for Practice
• Hands-on Scripting: Follow video tutorials (e.g., Adrianna Holden-Gouveia's "FAQ ShellScripting includes variables") to create and modify shell scripts.
• Experiment with echo: Try the different types of quotes (plain, double, single) with a "hello world" message and a variable to observe their distinct behaviors.
• Permissions Practice: Create a dummy file or folder, use ls -l to inspect its permissions, and then use chmod with octal numbers to alter permissions [Conversation History].
• Network Diagnostics: Open the terminal and practice pinging a website, and use ip a (or ifconfig) and ss to view active network connections [Conversation History].

--------------------------------------------------------------------------------