Paths, Wildcards, and Getting Around Fast

In one line

Absolute vs relative paths, and a handful of wildcard patterns, are what separate someone who painstakingly types full paths from someone who moves around a filesystem at the speed of thought.

0/4 · 0%

Think of it like this

Giving directions as 'turn left at the bank, then right' (relative — depends on where you're currently standing) versus '123 Main Street, Springfield' (absolute — works from anywhere, unambiguous). Both are valid; which one makes sense depends entirely on context.

Key ideas

01
An ABSOLUTE path always starts with / and describes a location from the root of the filesystem, unambiguously, regardless of where you currently are — e.g. /home/amit/projects/app.
02
A RELATIVE path does NOT start with / and is interpreted relative to your CURRENT directory (shown by pwd) — e.g. projects/app only means something once you know where you're standing. . means 'this directory' and .. means 'the parent directory' — cd ../../ moves up two levels at once.
03
The * wildcard matches any sequence of characters — ls *.log lists every file ending in .log in the current directory, and rm *.tmp deletes every .tmp file (a genuinely dangerous command to run carelessly — always ls the pattern first to see exactly what it'll match before using rm).
04
Tab completion is not optional flair — pressing Tab while typing a path auto-completes it (and lists options if there's ambiguity), which is dramatically faster and less error-prone than typing full paths by hand, especially for long or deeply nested ones.
05
~ is a shortcut for your home directory anywhere a path is expected — cd ~/projects and cd /home/amit/projects do the exact same thing if your home directory is /home/amit.

In your stack

→
A Spring Boot Dockerfile's COPY target/*.jar app.jar uses exactly this wildcard mechanism to copy whatever the build produced (the exact JAR filename usually includes a version number you don't want to hardcode) without needing to know the precise filename in advance.

Code & diagrams

paths-and-wildcards.shmarkdown

Try these against any directory with a mix of file types.

# Absolute path — works from anywhere
ls /etc/hosts

# Relative path — only means something from the current directory
cd /etc
ls ./hosts      # same file, relative syntax
cd ..           # up one level, now in /
cd ../..        # up two levels at once (harmless if already near the top)

# Wildcards — ALWAYS ls a pattern before you rm it
ls *.txt
ls **/*.log     # ** in bash needs 'shopt -s globstar' first to recurse

# ~ always means your home directory
cd ~
pwd

Explain it without notes

You're writing a script that will run on OTHER people's machines with different usernames. Should its file paths be absolute or relative, and why?

Why is ls *.tmp before rm *.tmp such a strongly recommended habit, given that rm is destructive either way?

Practice

From your home directory, use ONLY relative paths (., .., and plain names — no ~, no absolute paths) to navigate three directories deep and back to home again.

Create three throwaway files with different extensions (touch a.txt b.txt c.log) and use wildcards to list only the .txt files, then only files starting with the letter a or b.

Trade-offs

↔
Wildcards are powerful specifically because they're unforgiving — the same expressiveness that makes rm -rf project* fast also makes a typo (rm -rf project * — note the stray space, which makes it delete the CURRENT directory's entire contents plus anything matching 'project') catastrophic; the ls-first habit exists precisely because of this asymmetry.

Done when you can

I understand the difference between absolute and relative paths and when each makes sense.
I can use *, ., .., and ~ confidently while navigating.
I always ls a wildcard pattern before using it with rm.

Command Palette