pwsh: encodeEnvVarsForPowerShell rejects Windows-standard env var names like ProgramFiles(x86), breaking wsh token on every pwsh block
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
Research direction
Start in pkg/util/shellutil/tokenswap.go at EncodeEnvVarsForShell and encodeEnvVarsForPowerShell, then review IsValidEnvVarName in pkg/util/shellutil/shellquote.go. Confirm the PowerShell path handles names such as ProgramFiles(x86) while Bash and Fish retain their existing validation. Done means the pwsh encoding no longer aborts on Windows-standard names and still produces valid assignments.
Written by the indexing model from the issue text.
Description
Description
encodeEnvVarsForPowerShell in pkg/util/shellutil/tokenswap.go validates every environment variable name against the strict POSIX-identifier regex ^[A-Za-z_][A-Za-z0-9_]*$ (IsValidEnvVarName in pkg/util/shellutil/shellquote.go), and this validation is applied unconditionally to ALL shells in EncodeEnvVarsForShell, including pwsh.
Windows always defines environment variables containing parentheses, e.g. ProgramFiles(x86) and CommonProgramFiles(x86). These names fail the regex, so encodeEnvVarsForPowerShell returns:
invalid env var name: "ProgramFiles(x86)"
EncodeEnvVarsForShell propagates this as a hard error, which aborts the entire token exchange, not just the one offending variable.
Why this matters
This is not a cosmetic edge case, it fires on essentially every PowerShell block launch on Windows. Wave's own bundled pwsh shell-integration script (wavepwsh.ps1, generated for the pwsh shell type) runs:
wsh token $env:WAVETERM_SWAPTOKEN pwsh 2>$null
The 2>$null silently swallows the error, so the failure is invisible in normal use, but the entire env-var/init-script exchange for that block never runs.
Root cause
$env:ProgramFiles(x86) = "..." is invalid PowerShell syntax (parens are parsed as a command invocation), so the strict validator was presumably written to avoid emitting that. But PowerShell has a second, valid assignment form for exactly this case:
${env:ProgramFiles(x86)} = "..."
The ${env:NAME} delimited form tolerates parentheses (and most other characters) in the variable name. The validator doesn't need to reject these names for PowerShell at all, it just needs to emit the delimited form instead of the bare $env:NAME form.
Suggested fix
Scope the fix to encodeEnvVarsForPowerShell only (leave encodeEnvVarsForBash / encodeEnvVarsForFish untouched, the POSIX identifier rule is correct there):
- Emit
${env:%s} = %sinstead of$env:%s = %s. - Only reject a name if it's structurally impossible to express in that form (empty, or contains a literal
}), rather than requiring a POSIX identifier.
Environment
- Wave Terminal / wsh version: v0.14.5 (also present in current
mainas of this report,pkg/util/shellutil/tokenswap.gois unchanged on that path) - OS: Windows 11
- Shell: pwsh (PowerShell 7)
Repro
package main
import (
"fmt"
"github.com/wavetermdev/waveterm/pkg/util/shellutil"
)
func main() {
env := map[string]string{"ProgramFiles(x86)": `C:\Program Files (x86)`}
_, err := shellutil.EncodeEnvVarsForShell("pwsh", env)
fmt.Println(err) // invalid env var name: "ProgramFiles(x86)"
}
Or from a shell with any real Windows environment:
wsh token <valid-swap-token> pwsh
# Error: error encoding env vars: invalid env var name: "ProgramFiles(x86)"
- Dominant language
- Go
- Stars
- 22.3k
- Forks
- 1.1k
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from wavetermdev/waveterm
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
wavetermdev/waveterm#3435 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
wavetermdev/waveterm#3432 ·
-
enhancement triage
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
wavetermdev/waveterm#3431 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
wavetermdev/waveterm#3428 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
wavetermdev/waveterm#3355 · 1 comment ·
All issues in wavetermdev/waveterm
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100