How to run .sh file in Linux: a verified step-by-step guide

How to run .sh files safely and correctly in Linux

To run a .sh file in Linux, first make it executable with chmod +x script.sh, then run it with ./script.sh from the same directory or by providing the path. Before executing, review the script contents, ensure it comes from a trusted source, and confirm required dependencies are installed. This evergreen guide explains the steps, permissions, and safety checks needed for reliable execution across common distributions.

Understanding shell script files and execution methods

A .sh file is a plain-text shell script containing commands for Bash or another shell. It is not a binary; it is interpreted at runtime. You can invoke a script by calling its interpreter explicitly (bash script.sh) or by using an executable flag and a shebang (./script.sh). The shebang (e.g., #!/bin/bash or #!/bin/sh) tells the system which interpreter to use. Understanding these basics helps you choose the right method and troubleshoot common issues like exec format errors or permission denied messages.

Key concepts before execution

• Shebang: defines the interpreter path (e.g., #!/bin/bash)
• Permissions: the file must have the executable bit set to use ./script.sh
• Interpreter availability: required shell or tools must be installed
• Working directory: ./script.sh requires the script in the current directory or a provided path

Step-by-step: how to run a .sh file in Linux

Follow this sequence to run shell scripts safely and reliably.

1. Inspect the file: use cat or less to review the script contents before execution.
2. Check the shebang: confirm the first line specifies an interpreter (#!/bin/bash or similar).
3. Set executable permission: run chmod +x script.sh if it lacks the execute bit.
4. Run the script: use one of these options:
   • ./script.sh when in the same directory
   • /absolute/path/to/script.sh or relative path like ../folder/script.sh
   • bash script.sh or sh script.sh to explicitly invoke the interpreter
5. Confirm execution context: environment variables, current working directory, and user permissions affect behavior.

Command examples at a glance

Verify safety and contents before running any script

Never run a script you do not understand. Review the file line by line, check for suspicious network calls, file overwrites, or privilege escalation. If you obtained the script from a repository or forum, validate the author’s reputation and, when possible, run the script in a controlled environment such as a container or virtual machine. Use read permissions and auditing tools to limit risk.

Safety checklist

• Read the script from start to finish.
• Confirm the source is trustworthy.
• Ensure required tools are installed.
• Back up important data if the script modifies system settings.
• Consider using a test environment for complex or unknown scripts.

Set file permissions correctly for execution

Linux permissions control who can read, write, or execute a file. To run a .sh file as your user, you need the executable bit. You can manage permissions with chmod using symbolic or numeric modes. Common options include u+x (add execute for the owner) and a+x (add execute for all). Use ls -l script.sh to inspect current permissions; an executable script shows -rwxr-xr-x or similar. Correct permissions reduce friction when using ./script.sh and prevent permission denied errors.

Permission modes comparison

Run scripts by explicit interpreter when needed

If the shebang is missing or you need a specific interpreter, run the script by calling bash, sh, dash, or another shell explicitly. For example, bash script.sh invokes Bash regardless of the shebang. This method works when the script lacks execute permission and you prefer not to change it. It also helps when multiple shell versions are installed and you need to ensure compatibility by choosing the interpreter explicitly.

When to use explicit interpreter invocation

• Shebang is missing or incorrect
• You want to override the default shell
• Execute bit cannot be changed (e.g., read-only filesystem)
• Debugging script behavior under a specific shell

Troubleshoot common errors when running .sh files

Typical errors include permission denied, command not found, and syntax errors. Permission denied often means the executable bit is not set or the file is on a filesystem that prohibits execution (e.g., noexec mount). Command not found can indicate missing dependencies or an incorrect PATH. Syntax errors usually point to interpreter mismatches or hidden characters. Use set -e and set -x inside scripts, or run bash -n script.sh to check syntax without executing.

Common errors and fixes

Best practices for running shell scripts in production and daily use

Treat shell scripts as code: version control them, test changes in isolation, and document assumptions. Prefer explicit interpreters in controlled environments, and avoid running scripts as root unless necessary. Use sudo selectively, validate inputs, and log actions when feasible. Keep scripts small and focused, and leverage functions and sourced libraries for reuse. Automate safely by integrating checks and backups where appropriate.

Recommended workflow

• Review and validate script contents.
• Store scripts in version control.
• Use a virtual environment, container, or sandbox for initial testing.
• Set restrictive permissions (e.g., 700) when handling sensitive operations.
• Log outputs and errors for auditing.

Conclusion

Running .sh files in Linux is straightforward when you understand permissions, the shebang, and interpreter choices. Inspect scripts before execution, set appropriate permissions, and use explicit interpreter invocation when needed. By following safety practices and troubleshooting common errors methodically, you can execute shell scripts confidently and avoid common pitfalls.