If someone else had a cmdlet called, say, out-banner, and that cmdlet was already loaded in a snap-in (perhaps mandated by site policy), would I be able to register and add the Grrr snapin, which also defines it?

I’ve scanned the available documentation and the language grammar, used introspection in the shell and so on, but could not find anything to deal with this problem.

With projects like PowerShell Community Extensions seemingly laying claim to hundreds of common nouns and verbs, I was concerned that the scope for writing unique cmdlets would dry up real fast.

To determine what would happen, I registered and added Soapyfrog.Grrr, then wrote a new snapin, Soapyfrog.Conflict, with a single cmdlet, out-banner, conflicting with the one in Grrr.

I registered and added this, and was surprised that no warning of a conflict was given. To see if both were added, I tried this:

PS> get-command out-banner

CommandType     Name                        Definition
-----------     ----                        ----------
Cmdlet          Out-Banner                  Out-Banner [-Text] <Str...
Cmdlet          Out-Banner                  Out-Banner [-Text] <Str...

Interesting. Both are available, so what happens when I try to invoke it?

PS> out-banner hello
The term 'out-banner' resolved to a cmdlet name that is ambiguous. Pos
sible matches include: Soapyfrog.Grrr\Out-Banner soapyfrog.conflict\Ou
t-Banner.
At line:1 char:11
+ out-banner  <<<< hello

OK, so at this point, we know it’s possible to break existing PowerShell scripts by simply registering and adding a new snapin with a same-named cmdlet. Not good. Is there a work-around?

PS> Soapyfrog.Grrr\out-banner hello -fg 'o'
o   o ooooo o     o      ooo
o   o o     o     o     o   o
ooooo ooo   o     o     o   o
o   o o     o     o     o   o
o   o ooooo ooooo ooooo  ooo

Yes! We can fully qualify the cmdlet name with the snapin name and a backslash.

So, it’s not as bad as I first feared, but as I noted above, you need to be very careful about how you code and run scripts in environments where you can’t predict what snapins are registered and installed.

I suppose you can create the correct shell environment with Export-Console and run your script with:

powershell -psconsolefile xxx.psc1 -noprofile -command myscript.ps1

Or if your script requires a snapin, add the snapin in the script and fully qualify each cmdlet you use.

For example, cmd1 | cmd2 will run the two commands in separate processes.

PowerShell doesn’t do this. Everything runs in one thread, and pipelined objects are processed in batches, one bit at a time. You can control the batch size with the -outBuffer parameter, but things are still done sequentially, with one command in the pipe being busy whilst all others are sitting idle.

Even the venerable CMD.exe will put these two commands tree | more into separate processes.

This aside, what about simply running an arbitrary command (or scriptblock) in the background whilst doing something else?

PowerShell doesn’t have any obvious way to do this, but it is possible with runspaces. You can create a new runspace and then invoke a pipeline asynchronously.

Here is an example script, but lets go through it step by step.

$rscfg = [management.automation.runspaces.runspaceconfiguration]::Create()
$rs=[management.automation.runspaces.runspacefactory]::CreateRunspace($rscfg)
$rs.Open()

Here, we create a runspace with a default configuration. There is an overloaded version of CreateRunspace that takes a PSHost object, so we could pass in $host. In this case we just use the default. We then open the runspace.

$block = {
  $sum=0
  "adding numbers in background!"
  foreach($i in $input) {
    $sum+=$i
    start-sleep 1 # pretent it takes ages to compute this
    "adding number $i"
  }
  "that's it, sum is $sum"
}
$pipe=$rs.CreatePipeline($block)

Here we create the scriptblock $block that we want to run in the background and create a pipeline $pipe for it. The block itself simply takes it time adding up numbers passed to it, yielding textual information to the pipe, ending with the result.

$writer = $pipe.Input
$pipe.InvokeAsync()

Here we simply grab hold of the pipe’s input then invoke it asynchronously.

$numwritten = $writer.Write(1..5,$true)
$writer.Close()

This is where we give the background pipe some data to play with. Write(1..5,$true) means write the numbers 1 through 5 into the pipeline ($true means send the numbers one at a time instead of all at once).

1..3 | foreach { start-sleep 1; "busy in foreground $_" }

The whole purpose of this example is to show how two different things can be done at once, so here we simply spend 3 seconds pretending to be busy

$reader = $pipe.Output
while (-not $reader.EndOfPipeline) {
  $o = $reader.Read()
  write-host "$o"
}

Here we get the output $reader from the pipeline and whilst there is data, read an object and display it.

We didn’t have to do it this way; we could have read the whole thing in one go like this: $out = $reader.ReadToEnd(). The latter might be better if the background work produces a single result, but the line-by-line version may suit something with a lot of output. Although we simple do a write-host "$o" here, this could be a lengthy operation that would run whilst the background operation continues to do work.

$pipe.Error.ReadToEnd()
$pipe.Dispose()
$rs.Close()

Finally we consume any error output and clean up.

If you run the example script, you will see something like this:

busy in foreground 1
busy in foreground 2
busy in foreground 3
adding numbers in background!
adding number 1
adding number 2
adding number 3
adding number 4
adding number 5
that's it, sum is 15

This is great, but why is this post categorised as a rant? Well, it’s very long-winded and in my mind, async job scheduling is something that all shells should do.

It’s a pity PowerShell doesn’t let you do something like this:

{ foo | bar ; wibble}.InvokeAsync()

or

invoke-command -async { foo | bar ; wibble }

You can do this, however:

{ foo | bar ; wibble}.Invoke()

So how would all this be used? Would it make space invaders any quicker on a core duo pc? Only a profiler would know.

A single runspace can only have one asynchronous pipeline running and the pipeline cannot be reused. The setup costs are quite high, so you’d probably have to mess about with a single background pipeline reading work requests and writing them back.

Unfortunately, PowerShell (or rather .NET) doesn’t support them very well.

If I open up a “Command Prompt” window (CMD.EXE), I can do things like this:

CMD>echo Hello world > file.txt

CMD>echo Hello other world > file.txt:other

CMD>more < file.txt
Hello world

CMD>more < file.txt:other
Hello other world

As you can see, file.txt has two streams, the default one and one named other.

Back in PowerShell:

PS>gc file.txt
Hello world
PS>gc file.txt:other
Get-Content : Cannot find drive. A drive with name 'file.txt' does not exist.
At line:1 char:3
+ gc  < < file.txt:other

PowerShell doesn't like it. It incorrectly parses the part before the colon as a drive. Even if PowerShell did parse it properly, the underlying .NET bit would fail with System.NotSupportedException: The given path's format is not supported..

Perhaps Microsoft don't want people using ADS any more... or perhaps they're just not sure... if you Move-Item or Copy-Item the file, the extra stream is moved/copied intact.

Someone gave me an example of filtering an ASCII text file, stripping out the first 3 characters of each line.

On a Mac/UNIX box, you’d simply do:

cut -c4- infile.txt > outfile.txt

With PowerShell, you do:

gc infile.txt | % { $_.remove(0,3) } | sc outfile.txt

As an asside, on my machine, the latter takes 80 times longer to do the job on a 8MB text file than the former , but we’ll skip over that So, to the gotchas.

Gotcha 1 – text gets recoded

You might be tempted to do this instead:

gc infile.txt | % { $_.remove(0,3) } > outfile.txt

If you did, the resulting outfile.txt would be UTF16 and so be double the size of the original (less the cut 3 chars per line).

You might not notice this at first, as PS1 handles all this sort of thing transparently, but at some point, something might choke on it. You can be specific about output encoding, but that’s not something you might think about.

Gotcha 2 – path weirdness

My working area is: c:\Documents and Settings\adrian\My Documents\proj\top. That’s quite a lot to deal with, so I usually make it shorter by doing this:

new-psdrive -name doc: -psprovider filesystem -root "c:\Documents and Settings\adrian\My Documents"

so my working directory is actually doc:\proj\top. Much shorter, however, when I run the first command above, I get this:

PS doc:\\proj\\top> gc infile.txt | % { $_.remove(0,3) } | sc outfile.txt
Set-Content : The given path's format is not supported.
At line:1 char:42
+ gc infile.txt | % { $_.remove(0,3) } | sc  ﹤﹤﹤﹤ outfile.txt
The pipeline has been stopped.
At line:1 char:30
+ gc 100.txt | % { $_.remove( ﹤﹤﹤﹤ 0,3) } | sc outfile.txt
Set-Content : The given path's format is not supported.
At line:1 char:42

Odd that gc didn’t mind, but sc did.

You can’t even use resolve-path to fix it because if outfile.txt didn’t already exist, you’d get an error… maybe you need to use new-item -type file or something first?

To be honest, I gave up. PowerShell should really be making things easier, not throwing up barriers at every turn.

Adding to arrays

According to get-help about_array :

“You can append an element to an existing array by using the += operator. When the operator is used on the array itself, it appends the value.”

This isn’t completely true. If the right hand side of the += is also an array, then the elements of that array are added, not the array itself. This makes it very difficult to build up an array of arrays:

$a = @() # start with an empty array
$a += 1,2 # this doesn't work - it adds 1 and 2

so you need to do:

$a += 1
$a[-1] = 1,2

I think that either a) the documentation be updated to make this clear or b) fix += so it really does add the RHS as a new element. Otherwise, I’m going to have to use something like this, which is a bit ugly (but actually much more efficient):

$a = new-object collections.ArrayList
$a.add( @(1,2) )

Update: I’ve since discovered you can do this instead with the unary comma operator followed by a parenthesised list. The syntax is a bit weird (and hard to guess) but I believe the next version of PowerShell will get better documentation in this area.

$a=@()
$a += ,(1,2)

Integer division

Many languages support integer division, yielding an integer result. Many languages compliment this by offering a modulus division aswell. This is great, because one often has an index into a pseudo-2d array and you want to get the row and column values. Notionally:

width=10
offset = 17
row = offset DIV width
column = offset MOD width

This should yield row=1, column=7

In PowerShell:

[int]$width = 10
[int]$offset = 17
[int]$row = $offset / $width
[int]$column = $offset % $width

This yields a row of 2. The division, even though both sides are [int] is done using floating point and rounded up.

To work around it, we have to do this:

[int]$row = [Math]::Floor($offset/$width)

Not sure of a sensible fix for this… maybe a new operator like -idiv ? or the pythonesque //

Update: I’m not entirely sure what the problem is here… this site looks fine with IE6 on Win2k, but not on IE6 on my Wife’s XP. IE7 looks fine. There appear to be known problems with IE and PNG alpha, and overlapping PNGs, but I don’t know.

PowerShell is slow.

There are many ways to demonstrate this, but for this case I’m going to use a small snippet of code I found to render the mandelbrot set to the console window. It’s not my code and don’t know where it came from, but algorithm is fairly well known.

The code to demonstrate this is in a zip file here.

If you run ./mandel2.ps1 you get this pretty picture.

There is a Windows Scripting Host version. Run this with cscript mandel2.wsf.

There is a JScript.NET version. Compile it with JSC and or run the supplied one with ./mandel2.js.exe.

There is even a javascript-embedded-in-a-HTML-page version, just click on mandel2.html.

Now on my machine (a 2.66ghz quad core MacPro running XP in Parallels Desktop), I get these results:

OK, so the existing javascript engine in Windows (used by IE and WSF) are pretty good at this. Safari’s is pretty good (using KJS). So why is this brand spanking new language, PowerShell, so very poor?

It’s more than an order of magnitude slower than Microsoft’s previous attempt at a scripting environment!

This tardiness really shows itself in other inappropriate projects I’m working on in PS1. I really hope the PowerShell team at Microsoft address this for version 1.1 – maybe they should go speak to the jscript team.