Three Ways to Run a Script

You saved backup.sh, typed backup.sh, and got command not found. You tried ./backup.sh and got Permission denied. Then a friend's setup script "worked" but changed nothing in your terminal. All three puzzles have the same answer: how you run a script decides where it runs.

The rule

./ and bash run it in a child; source runs it here.

1. Direct execution. Give the file execute permission once, then run it by path:

This needs the shebang, because the system reads it to choose the interpreter. The ./ means "the file in this folder": your current folder is normally not on the PATH, so plain backup.sh is not found.

2. Running with bash. Hand the file to Bash yourself:

No execute permission is needed, and the shebang is just a comment now, since you already chose the interpreter.

3. Sourcing. Run the lines inside the shell you are typing in:

Both 1 and 2 start a child process: a fresh Bash that runs the script and then exits. Anything it changes about itself (its current folder, its variables) disappears with it. Sourcing starts nothing new, so a cd or a variable set in the file stays in your terminal. That is exactly how ~/.bashrc is loaded.

The shortcut

Ask one question: should this file change my shell? Tools like backup.sh just do a job, so execute them. Files that set up your environment (variables, folder, aliases) must be sourced. Then read error messages by their first word: command not found means a PATH problem (add ./), Permission denied means a missing execute bit (chmod +x, or use bash).

One warning: exit inside a sourced file exits your shell, which can close the terminal window. Keep exit in scripts you execute, not in files you source.

Drills

Answer fast — trust the rule.

Remember

• ./ and bash run a script in a child; source (or .) runs it here.
• Ask "should it change my shell?" Yes means source; no means execute.
• command not found means add ./; Permission denied means chmod +x. Never exit in a sourced file.