windows-shell-syntax

---

name: windows-shell-syntax description: Use when giving terminal commands on Windows or when comparing Windows vs Linux shell syntax. Detect whether the shell is PowerShell or cmd.exe before suggesting commands. Prevent Bash-only syntax from being given to Windows users. Covers quoting, escaping, chaining, env vars, line continuation, and safe rewrite patterns for cmd, PowerShell, and Bash.

---

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:
cmd:

Do not provide only one unlabeled command if syntax differs.

If version compatibility matters, prefer this structure:

PowerShell 5.1 compatible:
PowerShell 7+:
cmd:

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.

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.