cmd.exe is not a relic. It is the fastest shell on Windows, the default interpreter for most legacy build tools, and the environment where the netstat | taskkill combo that saves your blocked dev server actually works cleanest. This is a practical reference for the CMD workflows developers actually use, not a glossary of 70 commands with one-line descriptions.
| Tool | Best for | Script format | Startup time |
|---|---|---|---|
| cmd.exe | Quick one-liners, legacy tools | .bat / .cmd | Fastest |
| PowerShell | Automation, .NET objects | .ps1 | Moderate |
| Windows Terminal | Daily work, multiple shells | Both | Fast |
Where Does CMD Fit for Developers?
cmd.exe is not going anywhere. When you press Win + R and type cmd, you are in a prompt faster than PowerShell opens. Older build tools like MSBuild, some Java launchers, and plenty of legacy CI scripts still assume a CMD environment.
Use CMD when:
- You need a fast one-liner without loading a full shell
- You are running or debugging a
.bator.cmdscript - A legacy tool requires cmd.exe syntax
- You want the lightest possible environment for a quick check
Switch to PowerShell when you need loops, conditions, object manipulation, or anything that would require more than three lines in a batch file.
Process Management: Freeing Up Localhost Ports
This is the one CMD workflow every developer needs. Your dev server crashed, the process is still alive, and port 3000 is blocked.
Finding Stuck Dev Servers with netstat
netstat -ano | findstr :3000
The -a flag shows all connections, -n shows addresses numerically, -o shows the owning process ID. The findstr :3000 filters to your port. Output looks like this:
TCP 0.0.0.0:3000 0.0.0.0:0 LISTENING 14872
That last number is the PID you need.
Terminating Processes by Port Using taskkill
taskkill /PID 14872 /F
The /F flag forces termination. Without it, taskkill sends a graceful shutdown signal that a stuck process will ignore.
If you want to kill by name instead:
tasklist | findstr "node"
taskkill /IM node.exe /F
Use the image name (/IM) approach carefully, as it kills every instance of that process.
One-liner to kill everything on a port, combining both commands:
for /f "tokens=5" %a in ('netstat -ano ^| findstr :3000') do taskkill /PID %a /F
For a deeper look at killing processes by port across platforms, the kill process by port guide covers Windows, Mac, and Linux variants.
Environment Variables and PATH Troubleshooting
The most common developer CMD scenario: you install Python, Node, or a new CLI tool, open a terminal, and get 'python' is not recognized as an internal or external command. Here is how to diagnose and fix it.
Diagnosing Command Not Found Errors with where
where python
where node
where git
where searches your PATH in order and returns the full path to the executable. If it returns nothing, the tool is not in PATH. If it returns the wrong path (pointing to a virtualenv or an old installation), that tells you exactly which install is winning.
Check your current PATH:
echo %PATH%
This dumps the full PATH, semicolon-separated. Scan for the expected directory. If it is missing, continue to setx.
Safely Updating Your PATH with setx
setx PATH "%PATH%;C:\Users\YourName\AppData\Local\Programs\Python313" /M
The /M flag modifies the system PATH (requires admin CMD). Without /M, it only modifies your user PATH. For most dev tools, user PATH is enough.
Critical caveat: setx silently truncates values at 1024 characters. If your PATH is already long, running setx on it can corrupt the variable. Check the length first:
cmd /c "echo %PATH%" | find /v "" | find /c /v ""
Or in PowerShell: $env:PATH.Length. If you are at or above 900 characters, do not use setx. Instead, open System Properties (sysdm.cpl), go to "Environment Variables," and edit the PATH entry directly in the GUI. This bypasses the 1024-character limit entirely.
After running setx, close and reopen your terminal. The change takes effect in new sessions only.
To verify a tool is available after the fix:
where python && python --version
Package and Tool Management from the Command Line
Installing Dev Dependencies via winget
winget is Windows' built-in package manager. It is available on Windows 10 21H2 and later, and eliminates most GUI installer workflows.
winget install Git.Git
winget install OpenJS.NodeJS.LTS
winget install Microsoft.VisualStudioCode
winget install Python.Python.3.13
Search before installing:
winget search docker
Upgrade everything at once:
winget upgrade --all
winget installs happen in the background and require no browser downloads. The package IDs (like Git.Git or OpenJS.NodeJS.LTS) come from the Windows Package Community Repository. If you are unsure of the exact ID, winget search returns the correct string.
Navigation and File Operations for Build Scripts
Temporary Directory Switching with pushd and popd
pushd saves your current directory and moves to a new one. popd returns to the saved location. This is useful in build scripts where you need to run commands in a subdirectory without losing your starting point.
pushd C:\projects\myapp\scripts
call build.bat
popd
After popd, you are back where you started regardless of what build.bat did internally.
pushd also works with UNC paths, which plain cd does not support:
pushd \\server\share\builds
Batch Processing Project Files with forfiles
forfiles runs a command against a filtered set of files. The most common developer use case is cleaning up old log or build artifact files:
forfiles /p "C:\projects\myapp\logs" /s /m *.log /d -7 /c "cmd /c del @path"
Breaking down the flags:
/p- starting directory/s- recurse into subdirectories/m *.log- match only .log files/d -7- files older than 7 days/c "cmd /c del @path"- the command to run per file
For listing files instead of deleting (dry run):
forfiles /p . /s /m *.log /d -7 /c "cmd /c echo @path"
Always test with echo first.
Streamlining Local Testing and Build Workflows
Redirecting Output to Log Files for Debugging
When running builds locally, capturing output to a file lets you review errors without scrolling:
npm run build > build.log 2>&1
> redirects stdout. 2>&1 merges stderr into stdout so both land in the same file. Open the log after:
type build.log
Append instead of overwrite:
npm test >> test.log 2>&1
Chaining Commands for Multi-Step Workflows
Four operators control command chaining:
npm install && npm run build && npm test
&& runs the next command only if the previous one succeeded (exit code 0). This is your CI-style local check.
npm test || echo "Tests failed, check test.log"
|| runs the next command only if the previous one failed. Useful for cleanup or notification steps.
del old-build & npm run build
& runs both commands unconditionally, regardless of exit codes.
Combining for a resilient build script:
npm install && npm run build > build.log 2>&1 && echo BUILD OK || echo BUILD FAILED - check build.log
Using findstr as a Native grep Alternative
When you do not have ripgrep installed, findstr handles most quick in-file searches:
| Task | Command |
|---|---|
| Find "error" in a file | findstr "error" build.log |
| Case-insensitive | findstr /I "error" build.log |
| Recursive in directory | findstr /S /I "TODO" *.js |
| Multiple terms (OR) | findstr /I "error warning" build.log |
| Basic regex | findstr /R "^[0-9]" output.txt |
findstr regex is limited. It handles basic patterns but not lookaheads or named groups. For complex patterns, install ripgrep: winget install BurntSushi.ripgrep.MSVC, then use rg instead.
Running CMD as Administrator
Three scenarios where you will need an elevated prompt: running setx /M to modify the system PATH, running netstat to see processes owned by all users (not just your account), and editing system files like hosts.
Right-click "Command Prompt" in the Start menu and select "Run as administrator." The quickest shortcut: search for cmd in Start, then press Ctrl + Shift + Enter to open it elevated without the extra click.
From an existing CMD window:
runas /user:Administrator cmd
This prompts for the admin password inline.
For a complete list of ways to restart or control Windows from an elevated CMD session, the restart Windows from CMD guide covers all variants including remote and scheduled restarts.
Editing System Files from CMD
Two common developer tasks that require CMD with admin rights:
Editing the hosts file directly:
notepad C:\Windows\System32\drivers\etc\hosts
Running chkdsk before a suspected disk issue causes data loss:
chkdsk C: /f /r
The /f flag fixes errors, /r locates bad sectors. You will be prompted to schedule it on next reboot. For a deeper explanation of what each flag does and when to use it, the hosts file editing guide and the chkdsk reference cover both in detail.
CMD vs WSL for Development
If your workflow involves Linux tools (bash scripts, Docker, native Python packages with C extensions), WSL2 is a better environment than cmd.exe for those tasks. But the two are not mutually exclusive.
From CMD, you can launch a WSL session:
wsl
Or run a single Linux command without leaving CMD:
wsl grep -r "TODO" /mnt/c/projects/myapp
For when to use each and how WSL2 handles PATH and Windows interop, the WSL2 vs native Linux article covers the practical tradeoffs developers actually run into.
CMD handles the Windows-side workflows. WSL handles the Linux-side. Most Windows developers end up running both. The practical split: if the command involves a Windows path, a registry key, or a .bat script, stay in CMD. If it involves a package with native Linux compilation (some Python packages, Rust crates) or bash scripts from a Linux-first project, use WSL. Neither replaces the other.
