Windows Shell Syntax
Use this skill whenever the user is on Windows and asks for terminal commands, shell scripts, escaping rules, or asks to compare Windows and Linux terminal syntax.
First rule: identify the shell
Do not say "Windows terminal syntax" as if Windows had one shell.
On Windows, distinguish between:
- PowerShell (
powershell, pwsh)
- cmd.exe (
cmd)
- Git Bash / WSL bash (Unix-style shell on Windows)
Windows Terminal is only the terminal app. It can host multiple shells.
If the shell is unclear:
- Ask which shell they use, or
- Give separate
PowerShell: and cmd: variants.
Hard rule
Never give Bash-only syntax to a Windows user unless they explicitly said they are using:
- Git Bash
- WSL
- MSYS2
- Cygwin
- a Linux remote shell
Examples of Bash-only habits that must not be handed to cmd/PowerShell users without labeling:
export NAME=value$VAR for environment variables in cmd- backslash escaping like
\" as the default Windows answer
rm, mv, cp as if they were native cmd syntax- line continuation with
\
The && / || compatibility rule
Do not say "Windows does not support &&".
The real compatibility matrix is:
- cmd.exe: supports
&, &&, and ||
- PowerShell 7+: supports
&& and ||
- Windows PowerShell 5.1: does not support
&& and ||
- Git Bash / WSL: supports
&& and ||
This means the question is which shell and which PowerShell version, not just "Windows or not".
Safe default for uncertain PowerShell version
If you know only that the user is in PowerShell, but do not know whether it is:
- Windows PowerShell 5.1 (
powershell), or
- PowerShell 7+ (
pwsh / modern PowerShell)
then avoid && / || in the default answer and use explicit guarded logic instead.
Quick mapping
Escaping / quoting
cmd.exe
- Escape metacharacters with
^
- Typical special chars:
& | ( ) < > ^
- Example literal quote in a cmd snippet for users who need cmd escaping context:
^"
- Use
"..." for paths with spaces
- Environment variables:
%USERPROFILE%
- Line continuation:
^ at end of line
- Chain commands:
- always run next:
&
- next only on success:
&&
- next only on failure:
||
PowerShell
- Prefer single quotes
'...' for literal strings
- Double quotes
"..." are expandable: variables/interpolation work inside them
- Escape character is the backtick:
`
- Literal double quote often does not need escaping if you wrap the whole string in single quotes
- Environment variables:
$env:USERPROFILE
- Line continuation: usually avoid; if needed use backtick at end of line, but prefer splatting or parentheses for readability
- PowerShell 7+ supports
&& / ||
- Windows PowerShell 5.1 does not support
&& / ||
- When compatibility matters, prefer explicit
if checks over pipeline chain operators
Bash
- Escape character:
\
- Strong literal quotes:
'...'
- Expandable quotes:
"..."
- Environment variables:
$HOME, $VAR
- Line continuation:
\ at end of line
Safe answer pattern
When the user asks for a command and the shell is not specified, prefer this structure:
PowerShell:
<command>
cmd:
<command>
Do not provide only one unlabeled command if syntax differs.
If version compatibility matters, prefer this structure:
PowerShell 5.1 compatible:
<command>
PowerShell 7+:
<command>
cmd:
<command>
Rewrite rules
1. Command chaining
If you were about to write Bash chaining, rewrite for the actual shell.
- Bash:
cmd1 && cmd2
- cmd:
cmd1 && cmd2
- PowerShell 7+:
cmd1 && cmd2
- PowerShell 5.1 compatible:
cmd1; if ($?) { cmd2 }
Example:
PowerShell 5.1 compatible:
cmd1
if ($?) { cmd2 }
PowerShell 7+:
cmd1 && cmd2
cmd:
cmd1 && cmd2
2. How to replace &&
When a user says && does not work, first infer the likely shell:
- If they are in Windows PowerShell 5.1, replace:
cmd1 && cmd2 → cmd1; if ($?) { cmd2 }cmd1 || cmd2 → cmd1; if (-not $?) { cmd2 }
- If they are in cmd, keep
&& / ||
- If they are in PowerShell 7+,
&& / || are valid and usually can stay as-is
For native executables in PowerShell, a more explicit form may be safer when exit-code behavior matters:
cmd1
if ($LASTEXITCODE -eq 0) { cmd2 }
Use this especially when the left-hand side is an .exe or external CLI and you want to be precise about process exit codes.
3. Environment variables
- Bash:
export NAME=value
- PowerShell:
$env:NAME = 'value'
- cmd:
set NAME=value
For reading values:
- Bash:
$NAME
- PowerShell:
$env:NAME
- cmd:
%NAME%
4. Paths with spaces
Always quote Windows paths with spaces.
- PowerShell:
"C:\Program Files\App"
- cmd:
"C:\Program Files\App"
5. Embedded quotes
If the user is in cmd, remember ^ escaping for metacharacters and quote-sensitive cases.
If the user is in PowerShell, prefer changing quote style instead of piling on escapes.
Example:
PowerShell:
python -c 'print("hello")'
cmd:
python -c "print(^\"hello^\")"
Keep cmd examples minimal and tested-looking; cmd quoting gets messy fast.
6. Multi-line commands
Prefer shell-native multi-line styles:
PowerShell:
& python `
script.py `
--name test
cmd:
python ^
script.py ^
--name test
But if a one-line command is acceptable, prefer one line.
6.5 Quoting hell: prefer avoiding it
For cmd and PowerShell, deeply nested quoting can become fragile fast, especially for commands like:
python -c "..."- JSON passed inline on the command line
- regex patterns with both quotes and backslashes
- commands embedded inside another shell command
If quoting starts getting ugly, prefer a safer rewrite instead of trying to perfectly escape everything.
Preferred escape hatches:
- Put the content in a script file and run the file
- Put JSON in a file and pass the file path
- In PowerShell, prefer single quotes outside and double quotes inside when possible
- In cmd, prefer moving complex logic out of the command line entirely
- If both shells are possible, give a PowerShell variant rather than forcing a complicated cmd example
Rule of thumb: if the example needs a paragraph to explain the escaping, rewrite the approach.
6.6 Redirection/pipeline pitfalls: prefer simple patterns
Windows shells differ a lot in redirection and pipeline behavior.
- cmd pipelines are text-based
- PowerShell pipelines pass objects between commands
- stderr/stdout redirection can behave differently across native commands, cmd, and PowerShell
If a command depends on tricky redirection, prefer a simpler pattern:
- Write output to a file first, then read/process the file
- Run commands as separate steps instead of one dense pipeline
- In PowerShell, prefer explicit variables over clever pipeline chaining when clarity matters
- When giving a cross-shell answer, avoid advanced redirection unless you label shell-specific variants clearly
Rule of thumb: if correctness depends on subtle pipe/redirection semantics, choose a more explicit multi-step form.
7. Bash → Windows rewrite cheat sheet
Use this section when the user pastes a Bash command and wants the Windows equivalent.
cmd1 && cmd2
Bash:
cmd1 && cmd2
PowerShell 5.1 compatible:
cmd1
if ($?) { cmd2 }
PowerShell 7+:
cmd1 && cmd2
cmd:
cmd1 && cmd2
cmd1 || cmd2
Bash:
cmd1 || cmd2
PowerShell 5.1 compatible:
cmd1
if (-not $?) { cmd2 }
PowerShell 7+:
cmd1 || cmd2
cmd:
cmd1 || cmd2
export NAME=value
Bash:
export NAME=value
PowerShell:
$env:NAME = 'value'
cmd:
set NAME=value
echo $NAME
Bash:
echo $NAME
PowerShell:
echo $env:NAME
cmd:
echo %NAME%
~/file.txt
Bash:
cat ~/file.txt
PowerShell:
Get-Content $HOME\file.txt
cmd:
type %USERPROFILE%\file.txt
rm, cp, mv
Bash:
rm file.txt
cp a.txt b.txt
mv a.txt b.txt
PowerShell:
Remove-Item file.txt
Copy-Item a.txt b.txt
Move-Item a.txt b.txt
cmd:
del file.txt
copy a.txt b.txt
move a.txt b.txt
VAR=value command
This Bash pattern has no direct same-shape equivalent in PowerShell or cmd.
Bash:
NAME=value mytool
PowerShell:
$env:NAME = 'value'
mytool
cmd:
set NAME=value
mytool
If the temporary-only behavior matters, mention that Bash can scope env vars to one command, while PowerShell/cmd examples usually need extra cleanup if true one-command scope is required.
`command \
--flag value`
Bash:
command \
--flag value
PowerShell:
command `
--flag value
cmd:
command ^
--flag value
grep pattern file.txt
Bash:
grep pattern file.txt
PowerShell:
Select-String pattern file.txt
cmd:
findstr pattern file.txt
pwd and ls
Bash:
pwd
ls
PowerShell:
Get-Location
Get-ChildItem
cmd:
cd
dir
Note: ls and pwd may appear to work in PowerShell because of aliases, but if you are teaching shell syntax clearly, prefer the native command names.
Version detection hints
Use these heuristics when deciding whether && is safe in PowerShell:
- If the environment/tooling says
shell=powershell, that only tells you the shell family, not always the exact version
pwsh usually means PowerShell 7+powershell often means Windows PowerShell 5.1 on older/default Windows setups- If the user says "Windows PowerShell", assume 5.1 unless they say otherwise
- If the user says just "PowerShell" and compatibility matters, use the 5.1-safe form
If you need a detection command, give:
PowerShell:
$PSVersionTable.PSVersion
Response policy
When replying to Windows users:
- Infer shell from context if obvious.
- If not obvious, label commands by shell.
- Prefer PowerShell examples when the environment says
shell=powershell.
- If the user explicitly mentions
cmd or says ^", answer in cmd syntax.
- If converting from Linux/Bash to Windows, explain the key syntax changes briefly.
- Do not call PowerShell syntax "Windows syntax" if the distinction matters.
- If
&& is involved, distinguish cmd, PowerShell 7+, and PowerShell 5.1 instead of treating all Windows shells the same.
Minimal explanation to include when helpful
Use short phrasing like:
Windows Terminal is just the terminal app; the real syntax depends on whether you're running PowerShell or cmd.- In
cmd, escape special characters with ^.
- In PowerShell, the escape character is the backtick, and single quotes are usually the easiest literal form.
&& works in cmd and PowerShell 7+, but not in Windows PowerShell 5.1.
Notes
cmd commonly uses ^ for escaping special characters.- PowerShell quoting rules differ substantially from cmd.
- For maximum compatibility in PowerShell,
cmd1; if ($?) { cmd2 } is safer than assuming && support.
- When in doubt, provide both variants instead of guessing.
