For seven days I banned PowerShell and Bash from my daily driver. No pwsh, no Git Bash, no WSL for “just this one thing.” Only cmd.exe. The goal wasn’t nostalgia. It was to feel every sharp edge learners hit when corporate images still default to CMD-shaped workflows.
Rules of the experiment
- Work laptop tasks only through CMD (or GUI when CLI truly couldn’t).
- Scripts I needed had to be
.bat/.cmdor one-liners. - Notes went in a plain text file opened with
notepad. - Cheating = opening PowerShell. I logged every temptation.
Day 1–2: Quoting and delayed expansion
The first breakages were textbook:
set NAME=World
echo Hello %NAME%
Fine. Then loops and nested variables showed up, and delayed expansion (!VAR! with setlocal EnableDelayedExpansion) stopped being optional trivia. Several “simple” folder renames failed because paths with spaces weren’t quoted the way muscle memory from PowerShell suggested.
What broke: My assumption that “I know variables.” CMD variables are a different animal under expansion timing.
Day 3: Pipelines that aren’t pipelines
I reached for | expecting objects or at least sane text transforms. CMD pipelines are coarse. find, findstr, and for /f became the entire data toolkit. Parsing dir output felt like archaeology.
A log-filter task that is a one-liner in PowerShell became a brittle for /f "tokens=...". It worked until the column layout shifted. Classic.
What broke: Treating CMD like a junior PowerShell. It isn’t. It’s a different contract: strings, exit codes, and careful for /f.
Day 4: Error handling honesty
|| and && chaining helped. %ERRORLEVEL% discipline mattered more. I caught myself ignoring failed mkdir calls because “the folder probably exists.” In a teaching context, that’s exactly how juniors learn to shrug at failures.
What broke: Casual success bias. CMD won’t nag you with rich exceptions. You must ask.
Day 5–6: The jobs CMD still wins
Not everything was pain. A few tasks felt cleaner in CMD:
- Quick
copy,move,ren,delon constrained machines where PowerShell is execution-policy drama. - Reading ancient vendor
.batinstallers without translating them first. - Explaining “what the shell actually executed” without object formatting surprises.
On locked-down images, CMD remains the lowest-friction hammer for file ops. That week made the cliché visceral.
Day 7: What I’d teach differently
If I only showed PowerShell to Windows-first juniors, I’d be lying about their first week at many companies. Conversely, if I only showed CMD, I’d strand them before real automation.
The week’s scar tissue:
- Teach expansion and quoting as first-class, not footnotes.
- Teach exit codes before fancy tooling.
- Separate “survival CMD” from “automation PowerShell” without shaming either.
Temptations I logged (and what they meant)
| Urge | Why it appeared | CMD substitute |
|---|---|---|
Get-ChildItem -Recurse |
Finding logs deep in a tree |
dir /s + patience |
ConvertFrom-Json |
Reading API dumps | Redirect to file, open elsewhere (or suffer) |
$? rich errors |
Debugging failures |
%ERRORLEVEL% after every critical step |
Bash grep -R
|
Code search | findstr /s /i /n |
The table isn’t a recommendation to avoid PowerShell. It’s a map of skill gaps CMD-only work exposes quickly.
Would I repeat the week?
Yes—as a teaching exercise, once a year. No—as a lifestyle. The point was empathy: feel the quoting, feel the parser poverty, feel the places CMD is still the shortest path. Empathy improves curriculum more than hot takes do.
Unexpected upside
Reading ancient vendor installers without translating first made me faster in support calls. The week wasn’t only pain—it rebuilt respect for the lowest common denominator shell on Windows estates.
I channel that sequencing into interactive drills—one prompt at a time—at CMD Master, because the quit point is usually prompt friction, not theory.
What task would you refuse to do in CMD for a week, and why?
Top comments (0)