The same command, a different result · slopware 101

slopware 101 · step 2 of 35

The same command, a different result

by · 4 min read

A command can work in one terminal window and fail in another. Before changing the command, look at which folder each window is using. The same relative path can point at two different files.

What is a path?

A folder holds files and other folders, and those hold more. On macOS and Linux everything hangs from one starting point, the root, written as a single slash. Other disks, USB sticks included, show up as folders somewhere inside that one tree.

Windows draws it differently. Each drive has its own root, so C:\ and D:\ are separate trees, and a full path usually begins by naming the drive. Windows also writes the separators as backslashes, although many tools accept forward slashes too.

A path is directions through the tree. /Users/damla/Desktop/project means start at the root, go into Users, then damla, then Desktop, then project. On Windows the same idea reads C:\Users\damla\Desktop\project. Each separator is a door. A postal address does the same job in the same order.

Two kinds of path exist and they behave differently. An absolute path starts from a root, so it means the same thing wherever you are standing. A relative path starts from wherever you happen to be, so style.css means the one next to me, and the same name points at different files depending on where it is read from.

Where are you standing?

Open a terminal. On macOS it is called Terminal, most Linux desktops have one with the same name, and on Windows use PowerShell or Windows Terminal.

A command never runs in general. It runs while you are standing somewhere, and that changes what happens.

pwd

Print working directory. It answers with an absolute path, and every relative path you type gets measured from it. This one works on macOS, Linux and in PowerShell.

ls -F

This is the macOS and Linux version. Plain ls mixes files and folders together, and -F puts a slash after every folder. Do not guess from the name: README has no dot and is a file, backup.old has one and could just as easily be a folder. PowerShell has no -F, so run plain ls there and read the Mode column, where a d at the start marks a directory.

cd Desktop

Change directory, the same word in every shell. Desktop here is a relative path, meaning the Desktop inside where you already are. Run pwd again and the answer has grown by one step.

cd ..

Two dots means the parent directory. It gives you a way to move up without typing its whole path.

Is the terminal a different place?

Open Finder or File Explorer and go to your project folder. Put that window on one side of the screen and the terminal on the other, cd to the same folder and list it.

They are the same thing. The icons on one side and the names on the other are one folder described twice. Finder draws it, the terminal names it, and neither is deeper than the other. On macOS and Linux, names beginning with a dot are usually hidden from ordinary listings: use ls -a, or Cmd+Shift+. in Finder, to see them. Windows uses hidden-file attributes rather than the leading dot alone; ls -Force in PowerShell includes hidden items. Files such as .gitignore and .env will matter later.

Why does this decide whether things work?

Every build step, every deploy tool and every error message assumes you know where you are standing. File does not exist very often means a relative path was read from a folder you did not expect: the program looked for style.css next to itself, and itself turned out to be somewhere else. Nothing was missing and nothing was misspelled, the starting point moved.

This is one reason the same command can work locally and fail during deployment. Check the working directory before concluding that a file is missing.

There is a second difference hiding in names. macOS and Windows usually treat Style.css and style.css as the same file. Most Linux servers do not. A link that works on your laptop can point at nothing once it reaches a Linux machine, and the only change is one capital letter.

If you want more of this, MIT runs a free course for exactly this gap, The Missing Semester of Your CS Education, and Julia Evans draws comics about the shell that are the friendliest thing on the subject.

Without the editor

Open a terminal, leave the editor closed, and get to your project folder using only pwd, a listing and cd, reading what comes back after each one.

Then find one folder whose contents you cannot describe. There will be one, usually node_modules or dist or .next. Go in and look, change nothing. The next time something breaks, that folder is likely to come up.

The next chapter puts a single file in a folder and serves it, which is where the browser comes in.