Dash as a parameter crashes PWSH

[cawoodm]

PowerShell 6.2.0 on Windows 10

Steps to reproduce

test.ps1

[CmdletBinding()]param(
     [string]$p1,
     [string]$p2,
    [Parameter(ValueFromPipeline)][string]$InputObject
)
process{
    $input.replace($p1, $p2)
}

Run the following from CMD:

echo hello world | powershell -f test.ps1 e E
hEllo world
echo hello world | powershell -f test.ps1 e -
CRA$H@#*
echo hello world | powershell -f test.ps1 e "-"
CRA$H@#*

CRA$H@#* = PowerShell crashes

Expected behavior

h-llo world

Actual behavior

CRASH of pwsh.exe !

Environment data

Name                           Value
----                           -----
PSVersion                      6.2.0
PSEdition                      Core
GitCommitId                    6.2.0
OS                             Microsoft Windows 10.0.16299
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[cawoodm]

NB:

• This also crashes PowerShell v5
• It seems to be the dash - which crashes things
• It only crashes from CMD, run from within the powershell shell things work fine:

echo "hello world" | .\test.ps1 e -
h-llo world

[iSazonov]

@cawoodm Please share the content of test.ps1 file.

[cawoodm]

I've updated the original question with the code.

Just double-checked that it crashes PowerShell 6/Core (pwsh.exe) - it does:

C:>echo hello world | pwsh .\test.ps1 e -

[iSazonov]

Simple repo from cmd and pwsh:

pwsh any.ps1 -

any.ps1 : Cannot process argument because the value of argument "name" is not valid. Change the value of the "name" argument and run the operation again.
+ CategoryInfo          : InvalidArgument: (:) [any.ps1], PSArgumentException
+ FullyQualifiedErrorId : Argument,any.ps1

[iSazonov]

I debug the code and guess that it is "by design". In "pwsh any.ps1 -" we interpret the dash as parameter name prefix and get null as parameter name. If we run "> .\any.ps1 -" we interpret the dash as argument value.

I don't know can/should we fix this or no.

/cc @SteveL-MSFT @daxian-dbw @mklement0

[mklement0]

It happens only with (implied) -File, not with -Command.

With -Command, it behaves as expected: the - is interpreted as a positional argument rather than the start of an (invalid) parameter name.

While there are - regrettable^[1] - by-design differences between argument parsing with -File vs. -Command (literals vs. as-code), they should behave the same in this case (and, obviously, there shouldn't be a crash).

---

^{[1] In short: for conceptual clarity and predictable parameter passing (in line with POSIX-like shells), only ever the first argument following -Command should be interpreted as a snippet of PowerShell code, whereas all remaining arguments should be treated as literal arguments to pass as arguments to that first argument, as with -File.}

[iSazonov]

It seems the problem come from #4019 or #7449 (@TravisEz13 could you please look this too?)

PowerShell/src/Microsoft.PowerShell.ConsoleHost/host/msh/CommandLineParameterParser.cs

Lines 1133 to 1141 in ceed73d

	// Process interactive input...
	if (args[i] == "-")
	{
	// the arg to -file is -, which is secret code for "read the commands from stdin with prompts"
	_explicitReadCommandsFromStdin = true;
	_noPrompt = false;
	}
	else

Debug shows "i" has value 0 but I think it must be 1.

@mklement0 Look comment in the code.

[mklement0]

@iSazonov: looking at it purely from a behavioral perspective:

- is only special as the first - and then only supported - argument passed to -File - which is not the case here.

Since -f (-File) is used explicitly, #4019 shouldn't come into play - don't know anything about #7449.

As an aside: both -File - and -Command - are currently badly broken (the // Process interactive input... comment provides a hint) - see #3223

[TravisEz13]

Based on this comment #9362 (comment), this was not introduced in either of these PRs

[iSazonov]

@TravisEz13 I checked that Windows PowerShell 5.1 (10.0.17763.437) is not crashed.

[TravisEz13]

I think @mklement0 is correct here. There is a logic error in the code. It should verify the immediate parameter before was -file or -command