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:

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.