How to Run a .sh File: A Complete Guide to Executing Shell Scripts

Shell scripts are one of the most powerful tools in the Unix/Linux ecosystem — a way to bundle multiple commands into a single reusable file. But if you've just downloaded or received a .sh file for the first time, knowing how to actually run it isn't immediately obvious. Here's what you need to know.

What Is a .sh File?

A .sh file is a shell script — a plain text file containing a sequence of commands written for a Unix-like shell interpreter, most commonly Bash (Bourne Again Shell). When executed, the shell reads the file line by line and runs each command in order, just as if you'd typed them manually into a terminal.

Shell scripts are used for everything from automating software installations to managing files, scheduling backups, and configuring system settings. They're native to Linux and macOS, and can also run on Windows through compatibility layers like WSL (Windows Subsystem for Linux) or Git Bash.

Before You Run: Check the File First

Before executing any .sh file — especially one downloaded from the internet — it's good practice to read its contents.

Open it with any text editor, or use the terminal:

cat filename.sh 

Look for what it's doing. A trustworthy script will make its purpose obvious. Running an unfamiliar script with elevated privileges without checking it first is one of the more common ways systems get misconfigured or compromised.

How to Run a .sh File on Linux or macOS 🖥️

Method 1: Make It Executable, Then Run It

This is the standard approach. By default, downloaded files often don't have execute permissions set. You need to grant them first.

Step 1 — Open your terminal and navigate to the file's location:

cd /path/to/your/file 

Step 2 — Grant execute permission:

chmod +x filename.sh 

Step 3 — Run the script:

./filename.sh 

The ./ tells the shell to look for the file in the current directory rather than searching the system PATH.

Method 2: Pass It Directly to the Shell Interpreter

You can run a .sh file without changing its permissions by calling the interpreter explicitly:

bash filename.sh 

Or if the script is written for a different shell:

sh filename.sh zsh filename.sh 

This approach is useful when you don't want to modify file permissions or when you're testing a script quickly.

Method 3: Run with Elevated Privileges

Some scripts — particularly those that install software or modify system settings — require superuser (root) access. Prefix the command with sudo:

sudo bash filename.sh 

Only use sudo when the script explicitly requires it and you've verified what it does. Running arbitrary scripts as root can make system-wide changes that are difficult to reverse.

Understanding the Shebang Line

Most well-written shell scripts begin with a shebang (#!) — a special first line that tells the system which interpreter to use:

#!/bin/bash 

or

#!/usr/bin/env bash 

When you run a script with ./filename.sh, the OS reads this line and routes execution to the correct interpreter automatically. If no shebang is present, the system typically falls back to the default shell — but behavior can vary, which is why well-written scripts always include it.

How to Run a .sh File on Windows

Windows doesn't natively execute .sh files, but there are several practical options depending on your setup.

With WSL, you can open a Linux terminal and run .sh files exactly as you would on Linux. Git Bash provides a lighter Bash environment that handles most common scripts without a full Linux install.

Common Errors and What They Mean

Permission denied — The file doesn't have execute permissions. Run chmod +x filename.sh first, or invoke it with bash filename.sh.

No such file or directory — Either the path is wrong, or the script references a file that doesn't exist on your system. Double-check both.

Command not found (inside the script) — The script is calling a tool that isn't installed on your machine. Read the script's documentation or header comments for dependencies.

bad interpreter — The shebang line points to an interpreter path that doesn't exist on your system. Common when scripts are written on macOS and run on Linux, or vice versa.

Variables That Shape the Experience 🔧

Running a .sh file successfully isn't just one thing — the outcome depends on several factors that differ from system to system:

• Your shell and its version — Bash 3.x (still default on macOS) behaves differently from Bash 5.x on Linux in some edge cases
• User permissions — whether you're running as a standard user or have sudo access
• Installed dependencies — scripts often rely on other programs being present
• File encoding and line endings — scripts created on Windows may have Windows-style line endings () that cause errors on Linux; tools like dos2unix fix this
• The script's target environment — some scripts are written for specific distributions (Ubuntu, Arch, RHEL) and assume certain paths or package managers

A script that runs flawlessly on one machine can fail on another for any of these reasons — not because something is fundamentally wrong with either system, but because the environment doesn't match what the script expects.

What works smoothly for one person's setup may require several adjustments for another's — and that gap is entirely determined by the specifics of your own system and what the script was designed to do.