Creating a script file (.sh) in Bash Scripting - Mechanics & Internals

Overview - Creating a script file (.sh)

What is it?

A script file with the .sh extension is a plain text file containing a series of commands for the shell to execute. It automates tasks by running these commands in order, like a recipe for the computer. You create it by writing commands in a text editor and saving the file with .sh. Then you make it executable and run it to perform the tasks automatically.

Why it matters

Without script files, you would have to type commands manually every time you want to do a task, which is slow and error-prone. Script files save time, reduce mistakes, and allow repeating complex tasks easily. They are essential for automating system maintenance, software installation, and many daily computer jobs.

Where it fits

Before creating script files, you should know basic shell commands and how to use a terminal. After learning to create scripts, you can explore variables, loops, and functions in scripts to make them more powerful and reusable.

Mental Model

Core Idea

A .sh script file is a written list of shell commands that the computer reads and runs automatically.

Think of it like...

It's like writing a shopping list for someone else to follow exactly, so you don't have to tell them each item every time.

┌───────────────┐
│ Script File   │
│ (.sh)         │
├───────────────┤
│ #!/bin/bash   │
│ echo Hello    │
│ ls -l        │
└─────┬─────────┘
      │
      ▼
┌───────────────┐
│ Shell reads   │
│ commands one  │
│ by one and    │
│ executes them │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

What is a script file

Concept: Understanding that a script file is a text file with commands for the shell.

A script file is just a normal text file you create with any text editor. It contains commands you would normally type in the terminal. The file usually ends with .sh to show it is a shell script. For example, a file named hello.sh might have: echo "Hello, world!" This file can be run to print the message automatically.

Result

You have a file that stores commands to run later without typing them again.

Knowing that scripts are just text files helps you realize you can create and edit them easily with simple tools.

2

Foundation

Making a script executable

Concept: Scripts need permission to run, so you must make them executable.

After creating your script file, you must tell the system it can be run as a program. You do this with the command: chmod +x filename.sh This changes the file's permissions to allow execution. Without this, trying to run the script will fail.

Result

The script file can now be run directly from the terminal.

Understanding file permissions is key to controlling what can run on your system and keeping it secure.

3

Intermediate

Adding the shebang line

🤔Before reading on: do you think a script runs the same with or without the first line '#!/bin/bash'? Commit to your answer.

Concept: The shebang line tells the system which shell to use to run the script.

At the very top of your script, add: #!/bin/bash This line is called the shebang. It tells the computer to use the bash shell to run the commands inside the script. Without it, the system might use a different shell or fail to run the script properly.

Result

Scripts run consistently with the intended shell interpreter.

Knowing the shebang ensures your script behaves the same way on different systems and avoids unexpected errors.

4

Intermediate

Running a script file

🤔Before reading on: do you think you can run a script by just typing its name anywhere? Commit to your answer.

Concept: You run scripts by specifying their path or placing them in a directory in your PATH environment variable.

To run your script, you can type: ./filename.sh if you are in the same folder. The ./ means current directory. If you just type filename.sh, the system looks in special folders (PATH) and may not find it. You can also run scripts by calling the shell explicitly: bash filename.sh This runs the script without needing execute permission.

Result

You can run your script and see its output or effect.

Understanding how the shell finds and runs scripts helps avoid common errors like 'command not found'.

5

Intermediate

Editing scripts safely

Concept: Use plain text editors and avoid adding hidden characters.

Always create and edit scripts with plain text editors like nano, vim, or VS Code. Avoid word processors like Microsoft Word because they add formatting that breaks scripts. Also, save files with Unix line endings (LF) not Windows (CRLF) to prevent errors.

Result

Scripts run without syntax errors caused by hidden characters.

Knowing the right tools prevents frustrating bugs that are hard to spot.

6

Advanced

Using environment variables in scripts

🤔Before reading on: do you think variables set inside a script affect your terminal after it finishes? Commit to your answer.

Concept: Scripts can use variables to store and reuse information during execution, but changes usually don't affect the parent shell.

Inside your script, you can create variables: name="Alice" echo "Hello, $name" This prints Hello, Alice. However, if you set variables or change settings inside the script, these changes do not stay after the script ends unless you 'source' the script.

Result

Scripts can be dynamic and flexible, but their environment is separate from your terminal session.

Understanding the scope of variables helps avoid confusion about why some changes don't persist after running scripts.

7

Expert

Sourcing scripts vs executing

🤔Before reading on: do you think running a script with './script.sh' and 'source script.sh' do the same thing? Commit to your answer.

Concept: Sourcing runs the script in the current shell, so changes affect your session; executing runs it in a new shell process.

Normally, running a script like: ./script.sh starts a new shell process. Changes like variable assignments or directory changes do not affect your current terminal. But if you run: source script.sh or . script.sh then the commands run inside your current shell. This means variables set or directories changed stay after the script finishes.

Result

You can choose how scripts affect your environment, which is important for setup scripts.

Knowing the difference between sourcing and executing scripts is crucial for writing scripts that configure your environment correctly.

Under the Hood

When you run a .sh script, the system reads the first line (shebang) to find which shell program to use. It then starts that shell as a new process and feeds the script commands to it line by line. Each command runs in order, and the shell manages variables, input/output, and errors. The script runs isolated from your current shell unless sourced.

Why designed this way?

This design separates the script's environment from the user's shell to avoid unintended side effects. The shebang allows scripts to specify their interpreter, making scripts portable across systems with different shells. Running scripts as separate processes improves security and stability.

User Terminal
   │
   ▼
┌───────────────┐
│ Run script    │
│ (./script.sh) │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Shell process │
│ (bash)       │
│ Executes     │
│ commands     │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Script file   │
│ commands     │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does running a script always change your current terminal environment? Commit yes or no.

Common Belief: Running a script changes your current terminal environment permanently.

Reality: Running a script normally runs it in a new shell process, so changes like variables or directories do not affect your current terminal.

Why it matters: Expecting environment changes to persist can cause confusion and bugs when scripts don't behave as intended.

Quick: Is the .sh extension required for a script to run? Commit yes or no.

Common Belief: Scripts must have a .sh extension to run as shell scripts.

Reality: The .sh extension is a convention for readability but not required. The shebang line and execute permission determine how the script runs.

Why it matters: Relying on extensions alone can cause scripts to fail or run with the wrong interpreter.

Quick: Does adding the shebang line guarantee the script runs the same on all systems? Commit yes or no.

Common Belief: Adding #!/bin/bash ensures the script runs identically everywhere.

Reality: Different systems may have different bash versions or locations; some use /usr/bin/env bash for portability. Also, scripts may rely on system-specific commands.

Why it matters: Assuming perfect portability can lead to scripts breaking on other machines.

Quick: Can you run a script without making it executable? Commit yes or no.

Common Belief: You must always make a script executable before running it.

Reality: You can run a script by calling the shell explicitly (e.g., bash script.sh) without changing permissions.

Why it matters: Knowing this helps when you cannot change permissions but still want to run scripts.

Expert Zone

1

Scripts run in a subshell isolate changes, but sourcing scripts can cause hard-to-debug side effects if not used carefully.

2

Using /usr/bin/env in the shebang line improves portability by finding the interpreter in the user's PATH.

3

File permissions include read, write, and execute bits for user, group, and others; understanding this helps secure scripts.

When NOT to use

Avoid using shell scripts for complex applications requiring advanced error handling or performance; use languages like Python or compiled languages instead. Also, do not use scripts for tasks needing GUI interaction or heavy computation.

Production Patterns

In production, scripts are often modularized into smaller files, use logging for debugging, include error checking after commands, and are managed with version control. They are used for deployment automation, system monitoring, and scheduled tasks via cron.

Connections

Version Control Systems

Scripts are often stored and managed in version control systems like Git.

Understanding how to create scripts complements version control skills, enabling safe collaboration and change tracking.

Makefiles

Makefiles use shell commands to automate building software, often calling .sh scripts.

Knowing script files helps understand how Makefiles automate complex workflows.

Recipe Writing (Cooking)

Both involve writing step-by-step instructions to achieve a result.

Seeing scripts as recipes helps appreciate the importance of order and clarity in instructions.

Common Pitfalls

#1 Trying to run a script without execute permission.

Wrong approach:

./myscript.sh

Correct approach:

chmod +x myscript.sh
./myscript.sh

Root cause:

Not understanding that the system requires execute permission to run files as programs.

#2 Editing scripts with a word processor that adds formatting.

Wrong approach:

Creating script in Microsoft Word and saving as .sh

Correct approach:

Using nano or vim to create and edit plain text script files.

Root cause:

Not realizing scripts must be plain text without hidden formatting characters.

#3 Running a script without the shebang line and expecting consistent behavior.

Wrong approach:

Script without #!/bin/bash at top, run as ./script.sh

Correct approach:

Add #!/bin/bash as first line to specify interpreter.

Root cause:

Not knowing the shebang line tells the system which shell to use.

Key Takeaways

A .sh script file is a plain text file containing shell commands that automate tasks.

Making a script executable and adding a shebang line are essential steps to run scripts reliably.

Running a script normally starts a new shell process, so changes inside it do not affect your current terminal unless sourced.

Using proper text editors and understanding file permissions prevent common script errors.

Knowing when to source versus execute scripts is crucial for managing your shell environment.