Get-ChildItem -ForceWhat you should see Every item in the current directory, including the hidden and system items that a plain listing leaves out.
Read this as a study guide instead
Files and paths
Files, directories, and how a path names one thing exactly.
Check your own machine
These commands only read information — they change nothing. Run the block for your OS, then use the table to read your own numbers against the ideas above.
Windows
Get-Location
Resolve-Path .What you should see Get-Location prints the current directory (the pwd equivalent); Resolve-Path . returns its fully qualified absolute path.
Note Resolve-Path only resolves paths that already exist.
macOS
ls -laWhat you should see Every entry in the current directory, including hidden dot-prefixed names and the . and .. entries, exactly as on Linux.
pwd
pwd -PWhat you should see pwd prints the current directory as an absolute path; pwd -P prints the fully resolved physical path with every symlink followed.
Note readlink -f is GNU coreutils and is not standard on macOS, so pwd -P stands in to print the resolved absolute directory.
Linux
ls -laWhat you should see Every entry in the current directory, including hidden names that begin with a dot and the . (this directory) and .. (its parent) entries a plain listing omits.
pwd
readlink -f .What you should see pwd prints the current directory as an absolute path from the root; readlink -f . resolves the relative path . to that same absolute path.
| Concept | Windows | macOS | Linux |
|---|---|---|---|
| Current directory (an absolute path) | Get-Location | pwd | pwd |
| Resolve a relative path to its absolute form | Resolve-Path . | pwd -P | readlink -f . |
| List directory entries, including hidden ones | Get-ChildItem -Force | ls -la | ls -la |
The same ideas, as prose
These are the exact fragments the model serves — also available as an ordered study guide.
Naming one thing exactly
A computer holds thousands of files, and every one of them lives somewhere. The filesystem is what gives that somewhere a shape: a single tree of directories, growing from one root, with files sitting on its branches. A path is how you name exactly one file or directory in that tree — a single, unambiguous pointer to one thing.
That precision is the entire point. There may be a dozen files called notes.txt scattered across a machine, but there is only ever one /home/mia/notes.txt, because the path spells out the whole route to it. A bare name is ambiguous; a full path is not.
Everything else here builds on that one idea: what files and directories actually are, how a path is written and read, the difference between naming from the root and naming from wherever you happen to be, and why almost every "file not found" is really a path that pointed at the wrong place.
Files inside directories
A file is a named sequence of bytes — a document, an image, a program are all the same kind of thing underneath: a blob of data with a name attached. A directory (often called a folder) is a different animal: it stores no data of its own, only a list of other things — files, and more directories.
Because a directory can hold directories, which hold more directories, the whole filesystem nests into a tree. It works like boxes packed inside larger boxes, up to one outermost box — each box holding either items or still more boxes. There is exactly one outermost container, called the root, and everything else lives somewhere inside it, however many levels down.
That single-root tree is what gives every file one clear place. Follow the containment inward — root, then a directory, then a directory within that — and you arrive at the file, with no doubt about where it sits. The structure is the address system; a path is just how you write a route through it.
A path is directions
A path is the written route to a file: the sequence of directory names you pass through to reach it, one nested inside the next, ending with the file or directory being named. Spelled out, those names are joined by a separator character so the whole route reads as a single string.
Which separator you use depends on the operating system. macOS and Linux — the Unix family — use the forward slash /, so a path reads /home/mia/notes.txt. Windows uses the backslash \, as in C:\Users\Mia\notes.txt. The idea is the same either way: directory names, in order, with the target's own name last.
The separators between the names are what make the route unambiguous — each one means "now step into this next directory". Read left to right, a path is a set of directions, and following them lands on exactly one thing.
From the root or from here
There are two ways to write a path, and they differ in where they start counting. An absolute path starts at the root and gives the full route from there, so it means the same thing no matter where you are when you use it. On Unix an absolute path begins with /; /home/mia/notes.txt names that one file from anywhere on the system.
A relative path starts instead from the current directory — the directory you are working in at the moment — and gives directions from there. notes.txt on its own means the file of that name in the current directory, and mia/notes.txt means step into mia first. Two special names help: . refers to the current directory itself, and .. refers to its parent, the directory one level up.
The difference is like a full street address that works from anywhere versus 'two doors down', which only means something from where you are standing. An absolute path is portable and unambiguous but long; a relative path is short and convenient but only means something once you know where you are standing. Both name the same files — they just start counting from different places.
Walking a path to one file
Reading a path is a walk. The system starts at a base directory — the root for an absolute path, the current directory for a relative one — and takes the path one segment at a time. For each directory name in turn, it looks that name up in the directory it is currently standing in, steps inside, and repeats with the next segment.
Follow every segment successfully and the walk ends on exactly one file or directory: the single thing the path names. A .. segment steps back up to the parent instead of down, and on Unix even the root's parent is the root again, so a path can never climb above the top of the tree.
The walk can also fail, and it fails in a precise way. If any segment names something that is not there — a misspelled directory, a file that was moved — the lookup stops at that point and reports "No such file or directory". That message is not vague: it means resolution got partway down the route and then met a name that did not exist.
Extensions and hidden files
A file's name is just bytes, and the parts we read meaning into are conventions the filesystem does not enforce. The extension — the .txt in notes.txt, the .png in photo.png — is nothing more than the last piece of an ordinary name. Programs and operating systems use it as a hint about what the file contains, but the filesystem itself attaches no meaning to it; renaming notes.txt to notes.png changes the name and not a single byte of the contents.
A leading dot is a second convention. On Unix, a file whose name begins with . — like .gitignore or .bashrc — is treated as hidden: listing tools leave it out of their normal output unless you ask for everything. It is not locked or protected, only quietly skipped, which is why the small configuration files that should stay out of the way are named this way.
Neither habit is filesystem magic. An extension is a naming custom and a leading dot is a display custom; both live entirely in the characters of the name, and the filesystem stores them like any other bytes.
Every project is a pile of paths
Every real project is, underneath, a pile of paths. The program's configuration is loaded from a path; one source file imports another by path; the images and data a project ships are all referenced by path. Get one of those wrong and the piece is not found at all, even though nothing is actually broken.
That is why so much of the "file not found" family of bugs is really a path problem. The file exists, but the path pointed somewhere it is not — a typo, the wrong directory, or a relative path read from a different starting point than you expected. Because a relative path is resolved from the current directory, the same path can succeed from one place and fail from another, which is exactly how a program that worked yesterday stops working today.
The habit that saves you is small: know where a path starts from before you trust where it ends. When something cannot be found, check the current directory and whether the path is absolute or relative before deciding the file is gone — most of the time it is sitting right where it always was, and only the directions were off.