Bad formatting of call operator line

[sandersaares]

System Details

• Operating system name and version: Windows 10
• VS Code version:
  Version 1.14.2
  Commit cb82febafda0c8c199b9201ad274e25d9a76874e
  Date 2017-07-19T23:34:09.706Z
  Shell 1.6.6
  Renderer 56.0.2924.87
  Node 7.4.0
• PowerShell extension version: 1.4.1
• Output from $PSVersionTable:

Name                           Value
----                           -----
PSVersion                      5.1.15063.483
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.483
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

PS C:\Source\Windows2016-SetupIso> cd c:\
PS C:\> code -v
1.14.2
cb82febafda0c8c199b9201ad274e25d9a76874e
PS C:\> $pseditor.EditorServicesVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
1      4      1      0


PS C:\> code --list-extensions --show-versions
dbaeumer.vscode-eslint@1.2.11
donjayamanne.githistory@0.2.2
jebbs.plantuml@2.0.2
marcostazi.VS-code-vagrantfile@0.0.5
ms-vscode.PowerShell@1.4.1
qub.qub-xml@1.2.1
PS C:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.15063.483
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15063.483
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Issue Description

The following line is incorrectly formatted:

& $oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,b$isoPath\boot\etfsboot.com#pEF,e,b$isoPath\efi\microsoft\boot\efisys.bin $isoPath $outputPath

VS Code treats the first "#" as the start of a comment, whereas it really is just a part of the command arguments passed to the call operator. Furthermore, VS code formats the line by adding spaces after the commas, which breaks the command.

[rkeithhill]

The syntax highlighting (coloring part of the command as a comment) is handled by the https://github.com/powershell/editorsyntax project. Please file an issue there for that issue. But yeah, the code-formatter shouldn't be adding spaces after the commas in this case.

To be honest, I'm surprised this actually works at all given that # , are special characters to PowerShell. Array arguments to PowerShell are comma separated. But according to my echoargs util, this looks like it would work if the formatting didn't add the spaces:

Arg 0 is <c:\windows\img.exe>
Arg 1 is <-m>
Arg 2 is <-o>
Arg 3 is <-u2>
Arg 4 is <-udfver102>
Arg 5 is <-bootdata:2#p0,e,bc:\temp\foo.iso\boot\etfsboot.com#pEF,e,bc:\temp\foo.iso\efi\microsoft\boot\efisys.bin>
Arg 6 is <c:\temp\foo.iso>
Arg 7 is <c:\temp>

Command line:
"C:\Users\Keith\Documents\WindowsPowerShell\Modules\pscx\3.2.2\Apps\EchoArgs.exe" c:\windows\img.exe -m -o -u2 -udfver102 -bootdata:2#p0,e,bc:\temp\foo.is
o\boot\etfsboot.com#pEF,e,bc:\temp\foo.iso\efi\microsoft\boot\efisys.bin c:\temp\foo.iso c:\temp

@kapilmb With the spaces added, the above invocation changes significantly to this:

Arg 0 is <c:\windows\img.exe>
Arg 1 is <-m>
Arg 2 is <-o>
Arg 3 is <-u2>
Arg 4 is <-udfver102>
Arg 5 is <-bootdata:2#p0>
Arg 6 is <e>
Arg 7 is <bc:\temp\foo.iso\boot\etfsboot.com#pEF>
Arg 8 is <e>
Arg 9 is <bc:\temp\foo.iso\efi\microsoft\boot\efisys.bin>
Arg 10 is <c:\temp\foo.iso>
Arg 11 is <c:\temp>

Command line:
"C:\Users\Keith\Documents\WindowsPowerShell\Modules\pscx\3.2.2\Apps\EchoArgs.exe" c:\windows\img.exe -m -o -u2 -udfver102 -bootdata:2#p0 e bc:\temp\foo.is
o\boot\etfsboot.com#pEF e bc:\temp\foo.iso\efi\microsoft\boot\efisys.bin c:\temp\foo.iso c:\temp

[rjmholt]

Considering the problem a bit more, determining whether something is a native executable or not can only be done at runtime -- it's not something we can reliably do in PSScriptAnalyzer.

However, formatting an array is a very common scenario and I'm not sure it's possible for us to fix this without disabling array space insertion.

Basically trying to fix this without breaking other formatting scenarios is going to be fragile at best, and likely not possible in arbitrary cases.

My current recommendation would be to either:

• Wrap this native command argument in quotes, or
• Disable array space insertions

In future, we'll probably seek to address this with comment-based rule suppression (like with other linters).