Running scripts in Bash Scripting - Deep Dive

Overview - Running scripts

What is it?

Running scripts means telling your computer to follow a list of instructions saved in a file. These instructions are written in a scripting language like Bash, which the computer understands and executes step by step. Instead of typing commands one by one, you run the whole script to automate tasks. This saves time and reduces mistakes.

Why it matters

Without running scripts, you would have to type every command manually, which is slow and error-prone. Scripts let you automate repetitive tasks, making your work faster and more reliable. This is especially important for system maintenance, software installation, or any task you do often. Running scripts turns your computer into a helpful assistant that follows your exact instructions.

Where it fits

Before learning to run scripts, you should know basic command line usage and how to write simple Bash commands. After mastering running scripts, you can learn about script debugging, scheduling scripts to run automatically, and writing more complex scripts with variables and loops.

Mental Model

Core Idea

Running a script is like giving your computer a recipe to follow step by step automatically.

Think of it like...

Imagine you want to bake a cake. Instead of remembering each step, you follow a written recipe. Running a script is like handing the recipe to the computer so it can bake the cake for you without mistakes.

┌───────────────┐
│ Script file   │
│ (instructions)│
└──────┬────────┘
       │ run
       ▼
┌───────────────┐
│ Bash shell    │
│ (interpreter) │
└──────┬────────┘
       │ executes
       ▼
┌───────────────┐
│ Computer      │
│ performs task │
└───────────────┘

Build-Up - 7 Steps

1

Foundation

What is a script file

Concept: A script file is a plain text file containing commands for the computer to run.

A script file usually ends with .sh and contains lines of commands you could type in the terminal. For example, a script might have: echo "Hello, world!" This tells the computer to print Hello, world! on the screen.

Result

The script file holds instructions that can be run all at once instead of typing commands manually.

Understanding that scripts are just text files with commands helps you see how easy it is to automate tasks.

2

Foundation

Making a script executable

Concept: Before running a script, you must give it permission to be executed by the system.

Use the command: chmod +x script.sh This changes the file's permissions to allow it to run as a program.

Result

The script file becomes executable, so the system knows it can run it as a program.

Knowing about file permissions prevents errors when trying to run scripts that are not allowed to execute.

3

Intermediate

Running a script with path

🤔Before reading on: do you think typing just the script name runs it, or do you need to specify its location? Commit to your answer.

Concept: To run a script, you usually need to tell the system where it is by giving its path.

If your script is in the current folder, run it with: ./script.sh The ./ means 'this folder'. Without it, the system looks in other places and may not find your script.

Result

The script runs and executes all commands inside it.

Understanding how the system searches for commands helps avoid confusion when scripts don't run as expected.

4

Intermediate

Running scripts with Bash command

🤔Before reading on: do you think you can run a script without making it executable? Commit to your answer.

Concept: You can run a script by explicitly calling the Bash interpreter, even if the script is not executable.

Use the command: bash script.sh This tells Bash to read and run the script file directly.

Result

The script runs without needing executable permission.

Knowing this method helps when you cannot change file permissions but still want to run a script.

5

Intermediate

Using shebang for automatic interpreter

Concept: Scripts can start with a special line called shebang to tell the system which interpreter to use.

Add this as the first line in your script: #!/bin/bash This tells the system to use Bash to run the script when executed directly.

Result

The script runs with the correct interpreter automatically.

Understanding shebang lines makes scripts portable and easier to run on different systems.

6

Advanced

Running scripts with arguments

🤔Before reading on: do you think scripts can accept extra information when run? Commit to your answer.

Concept: Scripts can take input values called arguments to change their behavior when running.

Run a script with arguments like: ./script.sh arg1 arg2 Inside the script, $1 is arg1 and $2 is arg2. For example: echo "First argument is $1" This prints the first argument passed.

Result

Scripts become flexible and can do different things based on input.

Knowing how to pass and use arguments makes scripts reusable and powerful.

7

Expert

Running scripts in background and chaining

🤔Before reading on: do you think scripts always run one after another or can they run at the same time? Commit to your answer.

Concept: You can run scripts in the background or chain them to run sequentially or conditionally.

Run a script in background with: ./script.sh & Chain scripts with: ./script1.sh && ./script2.sh The && means run the second only if the first succeeds.

Result

You control script execution order and concurrency for complex automation.

Mastering background and chaining lets you build efficient workflows and handle errors gracefully.

Under the Hood

When you run a script, the system loads the file and passes it to the shell interpreter (like Bash). The shell reads each line, translates it into system calls or commands, and executes them one by one. If the script has a shebang, the system uses that interpreter automatically. File permissions control whether the system allows the script to run directly or requires calling the interpreter explicitly.

Why designed this way?

This design separates the script content from the interpreter, allowing flexibility to run scripts with different shells or languages. File permissions protect the system from running unauthorized or harmful code. The shebang line was introduced to simplify running scripts without typing the interpreter every time.

┌───────────────┐
│ User runs     │
│ script file   │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ OS checks     │
│ file permission│
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ OS reads      │
│ shebang line? │
└──────┬────────┘
       │yes/no
       ▼    ┌───────────────┐
┌───────────┐│ No: user calls │
│ OS launches││ interpreter    │
│ interpreter││ explicitly     │
└──────┬────┘└──────┬────────┘
       │           │
       ▼           ▼
┌───────────────┐ ┌───────────────┐
│ Interpreter   │ │ Interpreter   │
│ executes     │ │ executes     │
│ script lines │ │ script lines │
└───────────────┘ └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does typing the script name alone always run it? Commit to yes or no.

Common Belief: Typing the script name alone runs the script anywhere.

Reality: You must specify the path (like ./script.sh) unless the script is in a folder listed in your PATH environment variable.

Why it matters: Without specifying the path, the system won't find your script and will show an error, causing confusion.

Quick: Can you run a script without executable permission by just typing its name? Commit to yes or no.

Common Belief: Scripts run by name even if they are not executable.

Reality: Scripts need executable permission to run by name; otherwise, you must run them with the interpreter explicitly (e.g., bash script.sh).

Why it matters: Trying to run non-executable scripts by name leads to permission denied errors.

Quick: Does the shebang line affect running scripts when you call bash explicitly? Commit to yes or no.

Common Belief: The shebang line always controls how the script runs.

Reality: When you run a script by calling bash explicitly, the shebang is ignored because you already chose the interpreter.

Why it matters: Misunderstanding this can cause confusion about which shell runs the script and lead to unexpected behavior.

Quick: Does running a script in the background mean it finishes instantly? Commit to yes or no.

Common Belief: Background scripts finish instantly and don't use system resources.

Reality: Background scripts run concurrently but still take time and resources until they complete.

Why it matters: Assuming background means instant can cause errors in workflows that depend on script completion.

Expert Zone

1

Scripts run with different environments depending on how they are launched, affecting variables and paths.

2

Using exec to run a script replaces the current shell process, saving resources but changing behavior.

3

Scripts run with sudo may have different permissions and environment variables, which can cause subtle bugs.

When NOT to use

Running scripts manually is not ideal for repetitive or scheduled tasks; use cron jobs or systemd timers instead. For complex automation, consider configuration management tools like Ansible or scripting languages with richer features like Python.

Production Patterns

In production, scripts are often run by automation tools, scheduled with cron, or triggered by system events. Scripts include logging, error handling, and environment checks to ensure reliability. They are version-controlled and tested before deployment.

Connections

Cron jobs

Builds-on

Understanding how to run scripts manually is essential before scheduling them to run automatically with cron.

Software build automation

Same pattern

Running scripts is the core mechanism behind build tools that automate compiling and testing software.

Cooking recipes

Analogy

Just like running scripts automates tasks, following recipes automates cooking steps, showing how instructions guide processes in different fields.

Common Pitfalls

#1 Trying to run a script without executable permission by typing its name.

Wrong approach:

./myscript.sh
# Error: Permission denied

Correct approach:

chmod +x myscript.sh
./myscript.sh

Root cause:

Not understanding that the system requires executable permission to run scripts directly.

#2 Running a script without specifying the path when it is not in PATH.

Wrong approach:

myscript.sh
# Error: command not found

Correct approach:

./myscript.sh

Root cause:

Assuming the system searches the current directory for commands by default.

#3 Ignoring the shebang line and running the script with the wrong interpreter.

Wrong approach:

sh script.sh
# Script uses Bash features but sh runs it, causing errors

Correct approach:

bash script.sh
# Runs correctly with Bash interpreter

Root cause:

Not knowing that different shells have different features and syntax.

Key Takeaways

Running scripts automates tasks by executing a list of commands saved in a file.

Scripts must have executable permission or be run with an interpreter explicitly.

You usually need to specify the script's path to run it unless it is in your system PATH.

The shebang line tells the system which interpreter to use when running scripts directly.

Advanced running techniques include passing arguments, running scripts in the background, and chaining commands for complex workflows.