Running scripts on Windows is straightforward. Create a file, give it a .bat extension, then either call it in PowerShell or double-click it. Linux takes a slightly different path, but once you understand the steps, how to run a shell script in Linux becomes just as manageable.

What Makes Running a Shell Script in Linux Different

On Ubuntu and other Linux distributions, shell scripts use a .sh extension, not .bat. That’s the first thing to sort out before anything else.

The second difference involves permissions. Linux follows the principle of least privilege. When you create a file, the system gives it only the access it assumes you need — typically read and write. Execute permission is not included by default. Without it, any attempt to run the script produces a “permission denied” error. Knowing how to run a shell script properly means knowing how to handle this permission step first.

For a deeper look at how execute permissions work, file permissions and execute modes covers the full range of permission modes and when to use each one.

The Role of chmod When You Run Shell Script Files in Linux

The chmod command changes file permissions. To make a script executable, you apply chmod to the file before trying to launch it. The file owner then has permission to run it.

One important note: 777 is frequently used for convenience, but it grants full access to every user on the system — owner, group, and others. In most environments, that’s broader than necessary. For scripts containing anything sensitive, a more restricted mode is the better choice.

Permission Mode vs. Execution Access
700
Owner only
Owner can execute
750
Owner + group
Owner & group members
755
Owner, group, others (read)
Everyone can execute
777
Full access to all users — use with caution
Everyone — avoid in prod

Use 700 for scripts with sensitive operations, 750 when a team group needs to execute, and 755 for system-wide utilities. Refer to the guide on changing file permissions for the full breakdown of octal and symbolic notation.

The Dot Slash Notation When You Run a Shell Script

When you run a shell script from a terminal, you need to place ./ in front of the filename. This is not optional. Without it, the operating system searches the system PATH — a list of directories where it looks for programs — and won’t find your script there.

The ./ prefix tells the terminal to look in the folder you’re currently in, not across the entire system. That’s how Linux knows exactly which file you want to execute.

This same rule applies when you pass a script file directly to an interpreter like bash. Running bash script.sh skips the execute permission requirement, but ./script.sh requires it. Both are valid depending on the situation.

How to Run a Shell Script in Linux: Step-by-Step

These five steps walk through creating and executing a shell script from your Ubuntu home directory:

  • 1Make a dedicated folder to hold your script files
  • 2Inside that folder, create a file ending in .sh
  • 3Grant execute permission using chmod to avoid permission errors
  • 4Use ./ followed by the filename to run it in the terminal
  • 5Press CTRL+C to force-stop the script if it doesn’t exit on its own

Here’s what those steps look like as actual commands:

$ mkdir scripts
$ cd scripts
$ touch script.sh
$ echo 'echo hello-world' >> script.sh
$ chmod -R 777 .
$ ./script.sh
hello-world

Each line does one thing. mkdir scripts creates the folder. cd scripts moves into it. touch script.sh creates an empty file with the right extension. The echo line writes a simple command into the file. chmod -R 777 . applies execute permission to everything in the current directory. Finally, ./script.sh runs it, and the terminal outputs hello-world.

Common Errors When Running Shell Scripts in Linux

The three errors you’ll hit most often, and how to fix them:

Error Cause Fix
Permission denied Script lacks execute permission Run chmod +x script.sh
command not found Missing ./ prefix or wrong PATH Use ./script.sh from the correct directory
No such file or directory Wrong working directory or typo in filename Confirm path with ls before running

If a script runs but behaves unexpectedly, check the shebang line at the top. A line like #!/bin/bash explicitly tells Linux which interpreter to use. Without it, the system defaults to whatever shell is currently active, which may differ between environments.

Organizing and Moving Script Files After Creation

As you build more scripts, keeping them organized matters. The mv command handles directory moves cleanly and works well for restructuring a scripts folder after it grows.

The same chmod and ./ principles covered here carry over to other scripting languages. Running Python scripts in Linux follows a nearly identical permission and execution process, with the shebang line pointing to the Python interpreter instead.

FAQs

How do I run a shell script in Linux without execute permission?

Pass the script as an argument to the shell interpreter: bash script.sh. This bypasses the execute permission requirement entirely and works for quick, one-off script runs.

What does chmod +x do when running a shell script?

chmod +x adds execute permission to a file for all user categories — owner, group, and others. It’s the quickest way to make a script runnable without specifying a numeric mode.

Why do you need ./ to run a shell script in Linux?

Linux searches the system PATH directories for commands by name. Since your current directory isn’t in PATH by default, ./ explicitly tells the shell to look in the current working directory instead.

What is the difference between bash script.sh and ./script.sh?

bash script.sh calls the Bash interpreter directly and requires no execute permission. ./script.sh runs the file as an executable and requires chmod +x to have been applied first.

Can I run a shell script in Ubuntu as a different user?

Yes. Use sudo -u username ./script.sh to run it as another user, or sudo ./script.sh to run with root privileges. Both require appropriate sudo permissions on your system.

Willie has over 15 years of experience in Linux system administration and DevOps. After managing infrastructure for startups and enterprises alike, he founded Command Linux to share the practical knowledge he wished he had when starting out. He oversees content strategy and contributes guides on server management, automation, and security.