DeepDocs

A lot of teams discover the same problem the hard way. The project works, but the project shape doesn’t. A new engineer clones the repo, opens the terminal, and starts guessing which folders are canonical, which ones are leftovers, and which setup steps still matter.

That’s why a basic command like mkdir deserves more respect than it gets. If you care about repeatable onboarding, cleaner automation, and docs that people can trust, folder creation is not trivial. It’s one of the first places where engineering discipline shows up.

Quick summary

• mkdir is the standard command for creating folders in terminal workflows across Unix-like shells and Windows PowerShell, which makes it a near-universal developer skill (OpenClassrooms on mkdir).
• The most reliable habit is simple: check where you are, inspect the directory, then create the folder.
• mkdir -p is the command that scales when you need nested structures and scripting.
• Teams get the most value when they treat folder creation as part of project scaffolding, not an isolated shell trick.
• The real failure point usually isn’t the command. It’s stale setup documentation around the command.

Beyond the Basics Why Mastering the Terminal Matters

I’ve seen plenty of repos where the code quality was decent, but the structure around the code had grown by accident. A scripts folder existed in one service, tools in another, and some packages had docs/ while others buried setup notes in a wiki nobody updated. New hires didn’t struggle because they lacked terminal skills. They struggled because the team had stopped enforcing shape.

That’s why the ability to create folder in terminal workflows matters beyond beginner tutorials. It gives you a low-level way to express standards. If the expected structure is clear and scriptable, engineers stop inventing local conventions.

For people who still need a quick primer before standardizing team workflows, a basic guide on how to open Terminal helps, but the primary senior-level concern is what happens after the prompt appears.

Where teams usually go wrong

The common failure modes are predictable:

• Organic growth: folders appear because one person needed them once.
• Missing scaffolding: engineers recreate the same structure by memory.
• Stale READMEs: setup instructions describe a shape the repository no longer has.
• Local variation: every service ends up with a different layout for the same concept.

Practical rule: If engineers have to remember the directory structure instead of generating it, the structure isn’t standardized.

What mastery looks like

Mastery here isn’t memorizing flags. It’s using a small command as a control point for consistency.

A disciplined team uses terminal folder creation in three ways:

That shift is small in syntax, but big in effect. mkdir is where a lot of good engineering hygiene starts.

The Universal Foundations of Directory Creation

mkdir is one of those commands that looks too small to matter. In practice, it decides whether a team creates the same structure every time or drifts into a different layout on every machine.

The command name is literal: mkdir means “make directory.” You will use it in Unix-like shells, and you will also see it in PowerShell. That familiarity matters for teams working across macOS, Linux, and Windows, because setup instructions stay readable even when the shell differs.

The safe default workflow

A good habit is to treat folder creation as a four-step check, not a one-line impulse:

1. Check your current location
2. Inspect what already exists
3. Create the folder
4. Verify the result

In practice:

pwd
ls
mkdir docs
ls

I recommend this sequence because the common failure is not syntax. It is context. Engineers run mkdir from the wrong directory, create a valid folder in an invalid place, and then lose time cleaning up avoidable mistakes.

Single and multiple folders

For one directory:

mkdir project-name

For several at once:

mkdir src tests docs

That second form is more useful than it looks. It reduces typing, but the bigger benefit is clarity. A README that shows the intended top-level structure in one command is easier to review, easier to copy, and harder to misread.

Cross-platform behavior that teams can rely on

Teams do not need perfect command parity across every shell. They need commands that are predictable enough to document once and reuse.

• macOS and Linux: mkdir is the standard command.
• Windows PowerShell: mkdir also works in normal terminal workflows.
• Verification: many developers use ls in Unix-like shells, while PowerShell users may prefer their usual listing command.

That trade-off is fine. The important standard is the directory structure itself, not forcing every engineer to use identical shell habits for inspection.

A small command with documentation value

A beginner tutorial might show mkdir School and then ls to confirm it. Senior teams should read that same pattern differently. It is a minimal example of reproducible setup.

If a folder matters to the project, create it with an explicit command and document that command exactly. That keeps onboarding docs aligned with the repository, gives automation a clear starting point, and turns “create folder in terminal” from a basic skill into part of the team’s operating standard.

Build Complex Structures Instantly with Recursive Creation

The point where mkdir becomes powerful is the -p flag.

Instead of creating one folder, changing directories, creating the next one, and repeating the process, you can create a full nested path in one command. That changes the command from a convenience into a scaffolding primitive.

Manual creation doesn’t scale

Take a path like this:

src/api/v1/models

The manual version is annoying and brittle:

mkdir src
cd src
mkdir api
cd api
mkdir v1
cd v1
mkdir models

That’s too much surface area for mistakes. Someone forgets a cd, runs the command from the wrong directory, or writes docs that omit one of the steps.

Recursive creation is the professional default

Use this instead:

mkdir -p src/api/v1/models

If src, api, or v1 don’t exist, mkdir -p creates them automatically before creating models.

A practical example from Robservatory’s write-up on nested folder creation shows mkdir -p 202{0..5}/qtr{1..4}/week{1..13} generating over 330 folders in under a second. You don’t need that exact pattern every day, but it makes the point well. Recursive creation turns mkdir into an automation tool.

Here’s a quick visual walkthrough before using it in scripts:

Why -p is better in scripts

In setup automation, -p is usually the right default because it reduces dependency on exact prior state.

• Less fragile: scripts don’t need every parent folder created in sequence.
• More readable: one path expresses the intended hierarchy.
• Easier to review: a reviewer can understand the structure from one line.

If a repository has a canonical structure, mkdir -p should usually encode it directly.

Real examples that hold up

These are the patterns I see work well:

mkdir -p docs/guides/getting-started
mkdir -p services/auth/src
mkdir -p packages/ui/components
mkdir -p scripts/dev

What doesn’t work is mixing manual directory creation with implied team knowledge. If the path matters, write it down exactly. If it repeats, script it.

Handling Namespaces Permissions and Other Edge Cases

Once teams move from ad hoc terminal usage into scripts, edge cases stop being edge cases. They become routine.

Folder names may contain spaces. Build agents may run under different users. Shared environments may apply unhelpful defaults. Consequently, “it worked on my machine” starts showing up in directory creation too.

Names with spaces and special characters

If a folder name includes spaces, quote it.

mkdir "Project Blueprints"

Without quotes, the shell will often treat each word as a separate argument. That’s how you accidentally create multiple folders when you intended one.

A few practical rules help:

• Quote names with spaces: "Release Notes"
• Avoid decorative punctuation when you can: simple names are easier to script
• Prefer predictable casing: teams should decide between styles like docs/api and Docs/API, then stick to one

Permissions deserve intent

In shared systems and automated jobs, default permissions aren’t always what you want. That’s where -m can help set permissions at creation time.

mkdir -m 755 logs

The exact mode you choose depends on your environment and security model. The important point is procedural: don’t assume defaults are appropriate for every runtime context.

This matters in CI and service environments because a folder that exists with the wrong permissions can fail in ways that are annoying to diagnose. Engineers often chase the application error when the issue is the directory setup.

If you run into failures after a script creates directories, permission issues are often part of the picture. A separate guide on Bash permission denied errors is useful for that class of problem.

Treat permissions as part of setup, not cleanup.

Good naming beats clever naming

I strongly prefer folder names that survive copy-paste, shells, scripts, and docs without drama. That means:

The trade-off is simple. Human readability matters, but machine predictability matters too. In shared workflows, predictable usually wins.

From Manual Commands to Automated Project Scaffolding

The biggest upgrade isn’t learning one more flag. It’s deciding that engineers shouldn’t rebuild project structure from memory.

A scaffold script gives the repository a repeatable starting shape. That’s useful for new services, internal tools, demos, and even docs-only repos.

Start with a reliable sequence

A practical shell habit is to verify location with pwd, inspect with ls, and then create with mkdir. For nested paths, mkdir -p parent/child is more effective and reduces path-related errors, as shown in Simple Dev’s terminal folder guide.

That sequence belongs in scripts too. Blind creation from an unknown working directory is a common source of bad setup.

A simple scaffold script

#!/usr/bin/env bash
set -e
pwd
ls
mkdir -p src
mkdir -p tests
mkdir -p docs
mkdir -p scripts
mkdir -p .github/workflows
echo "Project structure created."

This is intentionally boring. Boring is good for setup.

If you want to make it more expressive:

#!/usr/bin/env bash
set -e
PROJECT_NAME="$1"
mkdir -p "$PROJECT_NAME"/src
mkdir -p "$PROJECT_NAME"/tests
mkdir -p "$PROJECT_NAME"/docs
mkdir -p "$PROJECT_NAME"/scripts

For anyone standardizing shell conventions, a compact Bash script cheat sheet is useful to keep nearby.

Why teams benefit from scaffolding

• Onboarding improves: new engineers don’t guess the structure.
• Repos stay consistent: one script can enforce one layout.
• Documentation gets simpler: docs can point to a single setup command.
• Reviews get cleaner: less debate about where things belong.

The hidden benefit is architectural clarity. When your script creates src, tests, docs, and scripts every time, you’re making a statement about how work should be organized.

Documenting Setup Commands So They Never Go Stale

A stale setup command can waste an hour before anyone realizes the repo is fine and the documentation is wrong.

That failure mode shows up in mature teams more than people admit. A scaffold script gains a new folder, a service gets renamed, permissions change, or the expected working directory shifts. The README keeps the old command block, a new engineer copies it, and the team burns time debugging a setup issue that was created by drift, not by code.

What good command documentation looks like

Keep setup instructions next to the scripts and conventions they describe. In practice, that usually means README.md or CONTRIBUTING.md, with the command shown exactly as a developer should run it.

./setup-project.sh my-service
cd my-service
ls

Then document the output, not just the command. If the script creates src, tests, docs, and scripts, say so. If one directory exists for CI, code generation, or deployment packaging, explain that too. Senior teams benefit from this because directory structure is part of architecture, and setup docs should make those decisions explicit.

The assumption worth challenging

Setup docs look harmless, so they often escape the discipline applied to application code. That is a mistake in active repositories.

• Scripts evolve: paths, arguments, and folder names change.
• Tooling evolves: generators and build systems introduce new directories or retire old ones.
• Review gaps persist: command examples get copied forward even after the implementation changes.

Documentation around shell commands tends to fail without obvious errors. That is why stale setup steps can survive for months.

Treat setup instructions like code. Put them under review. Keep them close to the script that creates the structure. Validate them in CI when the repository depends on repeatable scaffolding. For teams managing several services or templates, this is less about polish and more about control. The documented mkdir flow becomes the contract for how projects start.

If your repo setup changes often, DeepDocs is worth a look. It’s a GitHub-native way to keep documentation aligned with the code and scripts that define your project structure, so README setup instructions don’t drift out of date.