Ufdjrw

Can someone explain to me why I am seeing different output when I enter the same string one entered when prompted by powershell and the other when I pass by a variable. I would like to know how I need to format the string when entering it in the prompt to produce the same output that I get when I pass it as a variable.

test.ps1

param (
 [Parameter(Mandatory=$true)]
 [String]
 $NewArgumentString
)

$NewArguments = (Write-Output $NewArgumentString | ConvertFrom-StringData)
$NewArguments

Run:

PS> $testString = "HOSTNAME = jburns-test`nIP = 127.0.0.1"
PS> .test.ps1 -NewArgumentString $testString

Name Value
---- -----
HOSTNAME jburns-test
IP 127.0.0.1


PS> .test.ps1

cmdlet a.ps1 at command pipeline position 1
Supply values for the following parameters:
NewArgumentString: HOSTNAME = jburns-test`nIP = 127.0.0.1

Name Value
---- -----
HOSTNAME jburns-test`nIP = 127.0.0.1

The reason that this code responds differently to the prompt vs passing in a variable is because we are dealing with the difference between interpreted strings vs. literal strings. a.k.a. single quotes vs. double quotes.

Strings at the prompt are treated like literal strings, and not interpreted strings. That's why at the prompt you can't reference variables. To demonstrate the different effect this has with the example, let's run through it where we swap out the double quotes for single quotes in the passed variable, to emulate writing in the string at the prompt:

PS> $testString = "HOSTNAME = jburns-test`nIP = 127.0.0.1"
PS> $testString2 = 'HOSTNAME = jburns-test`nIP = 127.0.0.1'

PS> .test.ps1 -NewArgumentString $testString

Name Value
---- -----
HOSTNAME jburns-test
IP 127.0.0.1


PS> .test.ps1 -NewArgumentString $testString2

Name Value
---- -----
HOSTNAME jburns-test`nIP = 127.0.0.1

Here we see confirmation that the literal single quoted string is interpreted the same as the prompt is. What Really is going on is that the two strings are not the same. For the first double quoted string, immediately after the assignment, PowerShell converts the two character combination "`n" (0x96 + 0x6E) into the single Line Feed "LF" (0x0A) character. We can see this by comparing the string lengths:

PS> $testString = "HOSTNAME = jburns-test`nIP = 127.0.0.1"
PS> $testString.Length
37

PS> $testString2 = 'HOSTNAME = jburns-test`nIP = 127.0.0.1'
PS> $testString2.Length
38

To truly replicate the results of our theory in the example, let's enter into the prompt the -same- "bitwise" string that is stored in the variable by replacing `n with the non printable LF character (only possible by using the ALT + numpad method) ALT + 0010

PS> .test.ps1

cmdlet a.ps1 at command pipeline position 1
Supply values for the following parameters:
NewArgumentString: HOSTNAME = jburns-test
IP = 127.0.0.1

Name Value
---- -----
HOSTNAME jburns-test
IP 127.0.0.1

And voila! We have replicated the results. PowerShell is not broken. Our faith in functions and parameter passing is restored!

As an aside, it's probably not recommended to pass strings into your functions and rely on the function to convert it into a hash table, as that can give, as you have demonstrated, unpredictable results. I would instead directly pass in a Hash Table (Type [hashtable]) right into the function:

testHashTable.ps1

param (
 [Parameter(Mandatory=$true)]
 [hashtable]
 $MyHashTable
)

Write-Output $MyHashTable

PS> $testHashTable = @ "HOSTNAME" = "jburns-test" ; "IP" = "127.0.0.1" 
PS> .test.ps1 -MyHashTable $testHashTable

Name Value
---- -----
IP 127.0.0.1
HOSTNAME jburns-test