Command.CommandText doesn't display parameters

[TylerLeonhardt]

Command.CommandText doesn't display parameters... this leaves the extension in an awkward position because we pass around PSCommand's everywhere and there doesn't seem to be a friendly way of printing those out short of iterating over all the parameters ourselves.

I would have expected PowerShell to take care of this by default.

Steps to reproduce

[PowerShell]::Create().AddCommand("Get-Foo").AddParameter("WillThisShowUp", "Nope").Commands.Commands[0].CommandText

Expected behavior

Get-Foo -WillThisShowUp Nope

Actual behavior

Get-Foo

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.0-daily.20200418
PSEdition                      Core
GitCommitId                    7.1.0-daily.20200418
OS                             Darwin 19.4.0 Darwin Kernel Version 19.4.0: Wed Mar  4 22:28:40 PST 2020; root:xnu-6153.101.6~15/RELEASE_X86_64
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[bpayette]

@TylerLeonhardt PSCommand is just a property bags of strings, parameters etc. So it just contains the name of the command which won't be resolved until the PowerShell object is invoked. If you actually want any information about a command you really, really should be using CommandInfo objects.

But, it would be nice if the ToString() on PSCommand returned what you want. It would be even nicer if the PowerShell ToString() returned a complete syntactically valid pipeline string to support code generation. This would make it easier for app developers to implement "Show Me" functionality.

[SeeminglyScience]

Kinda complicated to do. For instance, what would it print here:

var obj = new object();
ps.AddCommand('Save-Object').AddArgument(obj);

[TylerLeonhardt]

Yeah that's tricky @SeeminglyScience. I would guess just calling ToString() on each parameter value / argument.

[SeeminglyScience]

What's the motivation if it can't accurately represent the command though? Just a visual aid?

Some other issues:

1. You'd have to add dot source/amp invocation operators too
2. Wrap scripts in scriptblocks
3. Add semi colons/new lines when AddStatement is used
4. What to show when the command is a manually constructed CommandInfo
5. How do you show MergeMyResults

Just to clarify I totally understand where you're coming from. I ran into the same thing and thought a while about how to get an accurate representation. I just want to make sure the aim isn't to get an equivalent invokable script, because there's too many scenarios where that will be super inconsistent. If the aim is instead to just get a "good enough" ToString to make it easy to see what the PSCommand currently holds then 👍 👍 from me

[TylerLeonhardt]

If the aim is instead to just get a "good enough" ToString to make it easy to see what the PSCommand currently holds then 👍 👍 from me

Yeah this is the idea.

[iSazonov]

In the case perhaps we need to have more descriptive name instead of ToString().

[JamesWTruher]

the CommandText property name is slightly misleading. It really should have been called "CommandName" (this is clear from the comment in the code). Rather than changing this property name, a new property could be created. However, this can also be done with an ETS extension external to the engine.