$x = 1
function changeit {
    "Changing `$x. Was: $x"
    $x = 2
    "New value: $x"
}
"`$x has value $x"
changeit
"`$x has value $x"

Not too complicated, right. Let’s see what happens when we run it:

$x has value 1
Changing $x. Was: 1
New value: 2
$x has value 1

What’s going on? Well, trying to change the value of $x inside the function did not work. Why not? What the statement $x = 2 actually does, is to create a local variable inside the function and give it the value of 2. Let’s fix that:

$x = 1
function changeit {
    "Changing `$x. Was: $x"
    $script:x = 2
    "New value: $x"
}
"`$x has value $x"
changeit
"`$x has value $x"

Now, we run it again:

$x has value 1
Changing $x. Was: 1
New value: 2
$x has value 2

The thing is that we have to explicitly tell Powershell to update the variable in the parent scope instead of creating a new variable in the current scope.

Når du installerer Windows 8, er det viktig at du har installert en-US som språk, og ikke bare norsk. Hvis ikke, vil Windows Store være så og si tom når du browser eller søker i den. For å finne oppsettet trykk Win, Win + F, søk etter “language” i “settings”.

Uten dette, er det fint lite å finne i Windows Store (per september 2012):

(Summary in English: if you are not native to the US, make sure you have en-US installed as a language in Windows 8. It does not have to be the preferred language. Otherwise, the Windows Store will probably have very little apps – only apps that explicitly supports your native language/culture)

function f($a, $b, $c) {
    "f: `$a=$a, `$a.GetType()=$($a.GetType())"
    "f: `$b=$b, `$b.GetType()=$($b.GetType())"
    "f: `$c=$c, `$c.GetType()=$($c.GetType())"
}
f 1 2 3   # call f with three integers as parameters
f 1,2,3   # call f with an array of three integers
f (1,2,3) # as above

The gotcha here is not to fall into the trap to use a C#-like or Java(Script)-like syntax where parameters are separated by commas. The comma in Powershell is always an array constructor operator, and takes precedence over function application. (Which also means that adding paranthesis will yield the same result). The code above will result in:

f: $a=1, $a.GetType()=int
f: $b=2, $b.GetType()=int
f: $c=3, $c.GetType()=int
f: $a=1 2 3, $a.GetType()=System.Object[]
You cannot call a method on a null-valued expression.
At ...\function-application.ps1:4 char:11
+ $b.GetType <<<< ()
    + CategoryInfo          : InvalidOperation: (GetType:String) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull
f: $b=, $b.GetType()=
You cannot call a method on a null-valued expression.
At ...\function-application.ps1:5 char:11
+ $c.GetType <<<< ()
    + CategoryInfo          : InvalidOperation: (GetType:String) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull
f: $c=, $c.GetType()=
f: $a=1 2 3, $a.GetType()=System.Object[]
You cannot call a method on a null-valued expression.
At ...\function-application.ps1:4 char:11
+ $b.GetType <<<< ()
    + CategoryInfo          : InvalidOperation: (GetType:String) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull
f: $b=, $b.GetType()=
You cannot call a method on a null-valued expression.
At ...\function-application.ps1:5 char:11
+ $c.GetType <<<< ()
    + CategoryInfo          : InvalidOperation: (GetType:String) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull
f: $c=, $c.GetType()=

$xml = [xml]'<root><item>1</item></root>'
$xml.Save('.\foo.xml')                              # Outputs nothing.
$xml.Save((join-path (pwd) -ChildPath '.\foo.xml')) # Actually writes

# line-gunk.ps1
"123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890"

If you run this Powershell file from the Windows command line, and redirects output to a file:

C:\>@powershell -file .\line-gunk.ps1 > foo.txt

Then you will get:

1234567890123456789012345678901234567890123456789012345678901234567890123456789
01234567890

However, if you do the redirection in Powershell, it’s fine:

PS C:\> .\line-gunk.ps1 > bar.txt

A näive fix to this, would be to change your script to use Write-Host to explicity write the text to the console. However, I consider this a bad practice because it would restrict the usage of your script as you could not manipulate the output further if reusing the script. I found this entry on stackoverflow which provides a better solution. Going back to the original script, here is a fixed one that worked for me:

# line-gunk-fixed.ps1
$Host.UI.RawUI.BufferSize = New-Object Management.Automation.Host.Size(500, 25)
"123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890"

Notice that I used the simplifed version from the stackoverflow entry, which might not work in all circumstances.

Backstory

How did I come across this problem? I running Powershell build scripts in TeamCity and I was trying to report the build progress back to TeamCity. However, it somehow did not work. I then discovered that the status messages written by my script were broken by the line breaks, rendering them useless…

The remote server returned an error: (407) Proxy Authentication Required.

Yes, I am behind a firewall that requires authentication. I found several references to this error message on the chocolatey forums, but they all seemed to be fixed in the latest chocolatey version.

Through some googling I was able to track down the problem. Acutally, it is a problem with the .NET 3.5 runtime that causes the System.Net.WebClient to give up on an NTLM authentication challenge from proxies. Chocolatey uses Powershell, and indeed the System.Net.WebClient to download installation packages (all though not the package manifest itself, where it uses NuGet). As you my or may not know, Powershell uses the .NET 3.5 runtime per default.

Hence, the fix was to make Powershell use the .NET 4.0 runtime, where this bug is fixed. I figured out how to do this based on this entry on stackoverflow.

I then wrote this little Powershell snippet which changes Powershell on my machine to use .NET 4.0 instead of .NET 3.5:

if ([Environment]::Version.Major -lt 4) {
    $configFile = Join-Path $PSHOME -ChildPath '.\powershell.exe.config'
    if (-not(Test-Path $configFile)) {
        @'
<?xml version="1.0"?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0.30319" />
    <supportedRuntime version="v2.0.50727" />
  </startup>
</configuration>
'@ | Out-File -FilePath $configFile -Encoding UTF8
        "Created $configFile"
    }
    'Restart powershell in order to make it run in .NET 4'
}

Wrong:

@'1
2
3
'@

Unrecognized token in source text.
At ...ps1:1 char:1
+  <<<< @'1
    + CategoryInfo          : ParserError: (:) [], ParseException
    + FullyQualifiedErrorId : UnrecognizedToken

@'
1
2
3'@

The string starting:
At ...:12 char:6
+ $s =  <<<< @'
is missing the terminator: '@.
At ...ps1:34 char:3
+ #> <<<<
    + CategoryInfo          : ParserError: (1
2
3'@
:String) [], ParseException
    + FullyQualifiedErrorId : TerminatorExpectedAtEndOfString

@'
1
2
3
'@

1
2
3

@'
@echo off
echo Wi nøt trei a høliday in Sweden this ÿer?
'@ > '.\Opening titles (unicode).cmd'
& '.\Opening titles (unicode).cmd'

Output: '■@' is not recognized as an internal or external command,
operable program or batch file.

@'
@echo off
echo Wi nøt trei a høliday in Sweden this ÿer?
'@ | Out-file '.\Opening titles (Ascii).cmd' -Encoding ASCII
& '.\Opening titles (Ascii).cmd'

Output: Wi n?t trei a h?liday in Sweden this ?er?

@'
@echo off
echo Wi nøt trei a høliday in Sweden this ÿer?
'@ | Out-file '.\Opening titles (OEM).cmd' -Encoding OEM
& '.\Opening titles (OEM).cmd'

Output: Wi nøt trei a høliday in Sweden this ÿer?

var index = (a == "a") ? 1 : 2;

In Powershell, such an operator is (to my knowledge) not available. One solution is described here. As an alternative without having to create a function and alias, I suggest:

$index = @{$true=1;$false=2}[$a -eq 'a']

Mmmmm, one-liner FTW

var ascii7BitEncoding = Encoding.ASCII; // ASCII
var ascii8BitEncodingIsh = Encoding.GetEncoding("iso-8859-1"); // Extended ASCII for almost all practical purposes

Where Extended ASCII differs from ISO-8859-*, according to Wikipedia:

One notable way in which ISO character sets differ from code pages is that the character positions 128 to 159, corresponding to ASCII control characters with the high-order bit set, are specifically unused and undefined in the ISO standards, though they had often been used for printable characters in proprietary code pages, a breaking of ISO standards that was almost universal.