How to Run a .sh File in Linux: A Complete Guide

Shell scripts are one of Linux's most powerful features — they let you automate tasks, configure systems, and execute sequences of commands with a single file. But if you're new to Linux or just haven't needed to run one before, the process isn't always obvious. Here's exactly how it works.

What Is a .sh File?

A .sh file is a plain text file containing a series of shell commands. When executed, Linux reads those commands and runs them in sequence — like a script for a play, but for your terminal. These files are typically written for bash (Bourne Again SHell), which is the default shell on most Linux distributions, though they can also target sh, zsh, dash, or others.

The .sh extension is a convention, not a requirement. Linux doesn't rely on file extensions to determine how to handle files — it looks at file permissions and content instead.

Step 1: Open a Terminal

Everything here happens in the command-line terminal. On most desktop Linux environments, you can open one with Ctrl + Alt + T or by searching for "Terminal" in your application launcher.

Navigate to the directory containing your script using the cd command:

cd /path/to/your/script 

To confirm the file is there:

ls -l 

Step 2: Check (and Set) Execute Permissions

This is the step most beginners miss. 🔑

Linux files have three permission types — read (r), write (w), and execute (x). A .sh file downloaded or created freshly often lacks execute permission, which means Linux won't run it as a program.

Check permissions with:

ls -l yourscript.sh 

You'll see output like:

-rw-r--r-- 1 user group 512 Jul 1 10:00 yourscript.sh 

The -rw-r--r-- string shows no execute permission. To add it:

chmod +x yourscript.sh 

After running that, ls -l will show something like -rwxr-xr-x, confirming it's now executable.

Step 3: Run the Script

Once permissions are set, you have a few ways to execute the file.

Method 1: Using ./ (Direct Execution)

./yourscript.sh 

The ./ tells Linux to look in the current directory for the file. This is the most common method and runs the script using whichever shell is specified in the file's shebang line (more on that below).

Method 2: Calling It with a Shell Explicitly

You can invoke a shell interpreter directly without setting execute permissions:

bash yourscript.sh 

Or for a different shell:

sh yourscript.sh zsh yourscript.sh 

This is useful when you don't own the file or can't modify its permissions — for example, on a shared system.

Method 3: Using the Full File Path

If the script is somewhere else on the system:

/home/user/scripts/yourscript.sh 

This works the same as ./ but with an absolute path. Execute permission still needs to be set.

Understanding the Shebang Line

The shebang (#!) is the first line of many shell scripts, and it tells Linux which interpreter to use:

#!/bin/bash 

or

#!/usr/bin/env bash 

If a shebang is present and you run the script with ./, Linux uses that specified interpreter automatically. If there's no shebang, the system typically falls back to sh (the basic POSIX shell), which may not support all bash-specific syntax.

When you call bash yourscript.sh explicitly, the shebang is ignored — the shell you named takes over regardless.

Running Scripts with Elevated Privileges

Some scripts need root access to modify system files, install software, or change configurations. In those cases:

sudo ./yourscript.sh 

Use sudo only when you understand what the script does. Running unknown scripts as root is a significant security risk — the script has full access to your system.

Common Errors and What They Mean

Variables That Affect How This Works

The specifics of running a .sh file aren't identical across every Linux environment. Several factors shape the experience:

• Your Linux distribution — Ubuntu, Fedora, Arch, and Debian each have slightly different default shells and PATH configurations
• Your default shell — bash, zsh, and fish handle certain syntax differently; a script written for bash may produce errors in a strict sh environment
• File origin — scripts downloaded from the internet, copied from Windows machines, or created in certain text editors may have Windows-style line endings () that cause errors; dos2unix yourscript.sh fixes this
• System permissions model — on multi-user or managed systems, your user account may not have permission to execute scripts in certain directories
• Script complexity — simple automation scripts behave predictably; scripts with dependencies, environment variables, or external tool calls may need additional setup before they run correctly

🗂️ A Note on Scripts You Didn't Write

Before running any .sh file from the internet or a third party, it's worth opening it in a text editor first:

cat yourscript.sh 

or

nano yourscript.sh 

Read through what it does. Shell scripts execute with your user's full permissions by default — and with sudo, they have root access. Understanding what a script does before running it is a basic and important habit, not just for security but for troubleshooting when things don't behave as expected.

Whether running a simple automation script or a complex system setup file, the method that works best depends on your shell environment, your permission level on the system, and what the script itself was written to do.