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:

text

PowerShell:
<command>

cmd:
<command>

Do not provide only one unlabeled command if syntax differs.

If version compatibility matters, prefer this structure:

text

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:

text

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:

powershell

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:

text

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:

text

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

text

Bash:
cmd1 && cmd2

PowerShell 5.1 compatible:
cmd1
if ($?) { cmd2 }

PowerShell 7+:
cmd1 && cmd2

cmd:
cmd1 && cmd2

cmd1 || cmd2

text

Bash:
cmd1 || cmd2

PowerShell 5.1 compatible:
cmd1
if (-not $?) { cmd2 }

PowerShell 7+:
cmd1 || cmd2

cmd:
cmd1 || cmd2

export NAME=value

text

Bash:
export NAME=value

PowerShell:
$env:NAME = 'value'

cmd:
set NAME=value

echo $NAME

text

Bash:
echo $NAME

PowerShell:
echo $env:NAME

cmd:
echo %NAME%

~/file.txt

text

Bash:
cat ~/file.txt

PowerShell:
Get-Content $HOME\file.txt

cmd:
type %USERPROFILE%\file.txt

rm, cp, mv

text

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.

text

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`

text

Bash:
command \
  --flag value

PowerShell:
command `
  --flag value

cmd:
command ^
  --flag value

grep pattern file.txt

text

Bash:
grep pattern file.txt

PowerShell:
Select-String pattern file.txt

cmd:
findstr pattern file.txt

pwd and ls

text

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:

text

PowerShell:
$PSVersionTable.PSVersion

Response policy#

When replying to Windows users:

1. Infer shell from context if obvious.
2. If not obvious, label commands by shell.
3. Prefer PowerShell examples when the environment says shell=powershell.
4. If the user explicitly mentions cmd or says ^", answer in cmd syntax.
5. If converting from Linux/Bash to Windows, explain the key syntax changes briefly.
6. Do not call PowerShell syntax "Windows syntax" if the distinction matters.
7. 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.