> Write-Host [Environment]::MachineName
And got back (literally)
[Environment]::MachineName
...which wasn't what he expected at all. It's worth pausing to consider why this happens.
Remember of course that when passing strings as arguments in PowerShell, the quotes are optional - it would make a fairly poor shell replacement otherwise. So for example the following is completely valid:
> Write-Host Hello!This is the reason[1] why variables in PowerShell have the dollar prefix - it makes their use in binding fairly unambiguous (just as the @ symbol in Razor achieves the same thing).
> $a = 'Moo'
> Write-Host $aMoo
If you really wanted to write '$a' you'd have to enclose it in single quotes (as I just did) or escape the dollar symbol.
Anyway back to the original problem, you can see that PowerShell has two possible ways of interpreting
> Write-Host [Environment]::MachineName
...and since it doesn't start with a $, you get the 'bind to as an object' behavior, which - in this case - gives you a string (since it's clearly not a number).
What you really wanted was one of the following:
> Write-Host ([Environment]::MachineName)
> Write-Host $([Environment]::MachineName)SOMECOMPUTERNAME
They both give the intended result, by forcing the expression within the brackets to be evaluated first (which on its own is unambiguous to the parser), and then passing the result of that as an argument to the bind for Write-Host.
This is really important trick to know, because will otherwise bite you again and again when you try and call a .Net method, and attempt to supply a parameter via an expression, for example:
$someClass.SomeMethod($a.length -1)
...when what you need to say is
$someClass.SomeMethod(($a.length -1))
Key take-home: When in doubt, add more brackets[2]
[1] presumably
[2] parenthesis
Posts
