Scripts and Permissions

Every command you've typed so far disappears when you close the terminal. Scripts fix that — they're files of shell commands that you can save, share, version-control, and run repeatedly. Once you can write a script, you can automate almost anything.

Writing your first script

Create a file called greet.sh:

touch greet.sh

Open it in any text editor and add these lines:

#!/bin/bash
echo "Hello, world!"
echo "Today is $(date)"
echo "You are running this as: $(whoami)"

The first line, #!/bin/bash, is called the shebang. It tells your operating system which interpreter to use for this file. Without it, the system might use the wrong shell (or none at all). Always start Bash scripts with #!/bin/bash.

File permissions and chmod

The shell protects you from running arbitrary files accidentally. File permissions control who can read, write, or execute a file — and scripts need execute permission before they can run. Try running the script:

./greet.sh

You'll likely see:

bash: ./greet.sh: Permission denied

Files are not executable by default. You need to grant execute permission:

chmod +x greet.sh
./greet.sh

Now you should see your output. chmod changes the mode (permissions) of a file. +x adds execute permission. The ./ prefix tells the shell to look in the current directory for greet.sh — without it, the shell only searches $PATH.

Reading permissions with ls -l

ls -l greet.sh

You'll see output like:

-rwxr-xr-x  1  alice  staff  65  Jun  9  2026  greet.sh

The first column is the permission string. Break it down:

- rwx r-x r-x
│  │   │   └── other: read and execute
│  │   └──── group: read and execute
│  └──────── owner: read, write, execute
└─────────── file type (- = file, d = directory)

r = read, w = write, x = execute, - = not set. After chmod +x, the x bits are turned on.

Positional arguments

Scripts become much more useful when they accept input. The shell provides special variables for arguments passed on the command line:

• $1 — first argument
• $2 — second argument
• $@ — all arguments
• $0 — the script's own name
• $# — the number of arguments provided

Update greet.sh:

#!/bin/bash
name=$1
city=$2
echo "Hello, $name!"
echo "Greetings from $city."
echo "This script is called: $0"

Run it with arguments:

./greet.sh Alice "New York"

Output:

Hello, Alice!
Greetings from New York.
This script is called: ./greet.sh

Notice the quotes around "New York" — without them, New would be $1 and York would be $2. Always quote arguments that contain spaces.

A practical script

Here's a script that creates a project directory with a standard layout:

#!/bin/bash
project_name=$1

if [ -z "$project_name" ]; then
  echo "Usage: ./new-project.sh <project-name>"
  exit 1
fi

mkdir -p "$project_name/src" "$project_name/tests" "$project_name/docs"
touch "$project_name/README.md"
echo "# $project_name" > "$project_name/README.md"
echo "Created project: $project_name"

Don't worry about the if syntax yet — the key takeaway is that scripts combine commands you already know (mkdir, touch, echo) with variables and simple logic to automate repetitive tasks.

Do it yourself

Write and run a script that greets you personally:

touch hello-me.sh

Add to the file:

#!/bin/bash
echo "Hello, $(whoami)!"
echo "You are in: $(pwd)"
echo "Your home directory is: $HOME"

Then:

chmod +x hello-me.sh
./hello-me.sh

Extend it: add $1 so you can pass a custom message as an argument.

Where to go next

You can now write, permission, and run shell scripts. Next: pipes and redirects — the |, >, >>, and < operators that let you compose commands into powerful data pipelines.