Scripts & Aliases

Recognise repetition

A script is a file containing commands that a shell can run in sequence. If you type the same setup or checking commands three or more times, consider automating them. For the studio scaffold, a script could create directories or print checks, but first learn what each command does by running it manually.

Automation reduces repetitive typing and makes a process consistent. It can also repeat a mistake quickly, so scripts should be short, readable and tested in a disposable folder before being used on important work.

Know the script formats

PowerShell scripts usually use the .ps1 extension. bash and zsh scripts commonly use .sh. The contents are shell-specific: a PowerShell command should not be assumed to run in zsh, or vice versa. A script starts with a sequence of commands and can include comments that explain why a step exists.

# Generic shell script idea
mkdir assets
ls

This small example illustrates commands in a file, not the complete quest scaffold. Before running a script, read it top to bottom and confirm its working directory and effects.

Run safely and check the result

Run a script using the method for your shell. PowerShell may apply an execution policy that blocks scripts; do not bypass security settings blindly—ask a teacher or inspect the policy guidance. On Unix-like shells, a script may need execute permission or can be passed to the shell directly. Never run a downloaded script you have not inspected.

After a script runs, list the files and compare the result with what you intended. If something is wrong, stop and fix the script before rerunning it; repeated runs may create duplicate or unwanted changes.

Aliases are shortcuts, not magic

An alias is a shorter name for a command. PowerShell’s familiar ls and ni are examples of aliases, while users can also define personal shortcuts in shell configuration. Aliases save keystrokes, but they can hide what a command really does and may not exist on another computer.

Use aliases for commands you understand and repeat, not to disguise risky actions. For the quest, you can build the folder tree directly first; later, script only the stable steps you have verified. That sequence helps you learn both the structure and the automation.

Save and run a harmless script

Use a disposable script-practice folder. A first script should only report location/listing, not delete or overwrite anything. For Mac, create inspect.sh in your editor:

#!/usr/bin/env bash
pwd
ls

Run bash inspect.sh from that folder. Passing the file to bash does not require making it executable. The output should show the current folder and its items; it does not automatically run relative to the script's folder if you launch it from somewhere else.

For PowerShell, create inspect.ps1:

Get-Location
Get-ChildItem

Run .inspect.ps1 from the same folder. If execution policy blocks it, inspect Get-ExecutionPolicy -List and the supported guidance for your machine. Do not broadly disable protections or bypass a managed school's/workplace's policy. You can still run and learn the individual harmless commands interactively.

Make a temporary alias you understand

In PowerShell, Set-Alias ll Get-ChildItem gives that command a short name for the current session; Get-Alias ll shows the mapping. In bash/zsh, alias ll='ls -l' gives a session-local shortcut; alias ll shows it. These are different mechanisms and disappear from a new session unless deliberately added to a profile.

Do not edit startup profiles merely to complete the scaffold activity. Do not give a dangerous command an innocent-looking alias. A colleague's terminal may not have your shortcut, so documented scripts should use clear supported commands.

Run the harmless script twice and explain why the output changes only if the folder's contents change. A later file-creating script should consider existing files and safe repeat runs. Automation is worthwhile only after you can explain and verify each step manually.