Explicitly importing associated modules error message contains invalid syntax

[Cryowatt]

Steps to reproduce

Create a Powershell DSC configuration like this:

Configuration MyConfig {
    Node localhost {
        File "Foo" {
            DestinationPath = "C:\Temp\Foo.txt"
            Contents = "Foo"
        }
    }
}

When you execute the configuration you'll end up with this error:

WARNING: The configuration 'MyConfig' is loading one or more built-in resources without explicitly importing associated modules. Add Import-DscResource –ModuleName 'PSDesiredStateConfiguration' to your configuration to avoid this message.

The given syntax isn't -ModuleName, it's –ModuleName. Look closely, that's not a hyphen (0x2D), that's an en dash (0x2013). If you copy and paste that back into [some powershell hosts] it's not going to like it.

Expected behavior

Hyphens

Actual behavior

En dashes

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.14393.953
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.953
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[mklement0]

if you copy and paste that back into powershell it's not going to like it.

Surprisingly, it is going to like it.

Unlike most other languages, PowerShell actually mostly recognizes (non-ASCII) Unicode whitespace and punctuation:

Take the following command, for instance:

Write-Host –NoNewline “$HOME” ‘literal’

With the exception of the hyphen in Write-Host, the whitespace and punctuation characters above are non-ASCII - including an en dash before NoNewline - yet it works:

• in the console / terminal

• in a script, assuming its file is UTF-8 with BOM (on Unix, the BOM is now optional)

I'm unclear on the exact rules and mapping, however.

The above suggests that at least command names only work if you spell them exactly as defined (case differences aside).
While probably ill-advised, you could define a function/script with en-dash for instance, in which you'd also have to invoke with an en-dash.

[Cryowatt]

Well I guess I should have tested in it a regular console window, but it seems that the loose Unicode handling is a host-specific thing as this definitely did not work in a VSCode embeded powershell terminal.

[mklement0]

Actually, it does work in VSCode's PowerShell terminal, and it should work anywhere the Unicode encoding is preserved - but that perhaps points to the reason to better stick with ASCII: things may get lost in translation (transcoding)...

[mklement0]

@Cryowatt, could you please change the title to prevent confusion? It's not about invalid syntax, it's about unexpected use of (non-ASCII) Unicode punctuation.

[BenJTucker]

+1 for this. powershell didn't like it on my machine, in vscode.

The failure condition is really weird too, with powershell complaining about unterminated quotes on the last line with double quotes in it.

Fwiw, this sure looks like invalid syntax to my environment.

[mklement0]

@BenJTucker

That suggests that your file is UTF-8 without a BOM, which is a general problem you should address, because Windows PowerShell will misinterpret all non-ASCII-range characters in your file.
In other words: your problem is an improperly encoded file, not the use of a en en-dash in lieu of a hyphen in the command.

With a properly encoded file, you can copy the command from the error message - Import-DscResource –ModuleName 'PSDesiredStateConfiguration' as-is, and it will work.

That en-dashes also work in the integrated VS Code terminal can be verified by copying and pasting the following command, which should work: get-date –year 42

[BenJTucker]

I had a working script and I pasted in literally what the error message told me to. Then I had a broken script.

[vexx32]

Indeed. Point being that PS itself should use errors that use the correct, unambiguous characters to avoid as many issues for the user as possible. Encoding is something that commonly has to be dealt with, but preferably we should avoid having to worry about encoding while handling what an error message has given us verbatim.

[Cryowatt]

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_command_syntax?view=powershell-6#parameters states that

In a PowerShell command, parameter names always begin with a hyphen. The hyphen tells PowerShell that the item in the command is a parameter name.

It doesn't say that parameter names can start with whatever horizontal line you feel like at the time.

[vexx32]

Yeah. PS does attempt to parse other types of horizontal dash to make one's life easier, just like it tries to parse fancy quotes that MS Word and Outlook like to convert things into without asking.

Unfortunately, with how encodings sometimes trip things up, it can't work 100% of the time.

[mklement0]

Agreed, @vexx32 - it's worth switching to a hyphen.

That said, the error message isn't part of this repo, and it looks to me that the DSC code may not have been open-sourced (yet?), so the correct place to report this issue is https://windowsserver.uservoice.com/forums/301869-powershell?category_id=148047

---

Separately, it's important to understand the true issue here, and the true issue is one of character encoding. A lack of awareness of that can cause other problems down the line.

@Cryowatt: Whether it's documented or not, PowerShell does support this substitution, as it does with other punctuation and quote characters, as @vexx32 mentions - see this Stack Overflow answer for details.

@BenJTucker:
Your script will only work as long as it contains only characters in the ASCII range (7-bit, code points 0 through 127), because both UTF-8 and ANSI encodings (the default in Windows PowerShell) share that range.

While you may have no plans to use non-ASCII-range characters, know that saving your scripts as UTF-8 without BOM will cause Windows PowerShell to misinterpret them as ANSI-encoded, once you add a non-ASCII-range character - and as you've experienced, that can happen through copy and paste.

The best cross-edition and cross-platform choice of encoding is UTF-8 with BOM.
VS Code defaults to UTF-8 without BOM, which generally makes sense, but causes problems with Windows PowerShell (but not PowerShell Core).

Lack of API support has so far prevented the PowerShell extension for VS Code from defaulting new PowerShell files to UTF-8 with BOM - see this issue, which also shows how you can manually configure VS Code that way.

[microsoft-github-policy-service]

This issue has been marked as won't fix and has not had any activity for 1 day. It has been closed for housekeeping purposes.