Category: PowerShell

As Hal Rottenberg pointed out earlier, some interesting news has surfaced about the next version of PowerShell (2.0?).  According to an article about WinRM, there is a CTP of PowerShell coming before the end of the year and this CTP will support running cmdlets against remote computers using WinRM as the remote transport protocol.  My bet is that this will be released at the TechEd IT Forum 2007 conference in November.  Here’s the snippet from the article:

Something else to consider. Sometime before the end of the year an upgraded CTP (Community Technology Preview) version of Windows PowerShell will be released, an upgrade that will enable you to run most Windows PowerShell cmdlets against remote computers. The catch? This new version of Windows PowerShell also relies on WinRM as its remote transport protocol. If you’re interested in using Windows PowerShell to manage remote computers you’ll need to download and install WinRM on your Windows XP and Windows Server 2003 machines.

If you haven’t gotten up to speed on WinRM already, now’s the time to start!

Kirk out.

Technorati Tags: PowerShell, PoSh, Poshoholic, WinRM
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

You know that scene in “The Matrix” where they download programs into Neo’s mind so that he can learn more quickly?  I need to get myself one of those for PowerShell.

The more I learn about PowerShell the more I realize there is to learn and the more I want to know.  I am such a Poshoholic!

Kirk out.

Technorati Tags: PowerShell, PoSh, Poshoholic
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

Earlier today Ying Li over at myITforum.com posted an article about some of the difficulty involved in launching a Windows PowerShell script from cmd.exe (or Start | Run) when there is a space in the path to the ps1 file containing the script.  In this article, Ying was pointing out how running a script with a command similar to the following will result in an error:

powershell -noexit & “C:\Documents and Settings\poshoholic\My Documents\PowerShellRocks.ps1”

The reason this generates an error is simply because of how the command line arguments are broken into tokens outside of Powershell and then rebuilt as arguments inside of PowerShell.  In the example above, PowerShell is being executed with 3 arguments: -noexit, &, and the path to the PowerShell script.  Even though the PowerShell script has quotation marks around it when it is entered in cmd.exe or in the Start | Run dialog, those quotation marks are only used to hold the string together as one argument outside of PowerShell.  They are not passed in with the string.  When PowerShell actually gets to see the arguments inside, it sees this:

1. -noexit
2. &
3. C:\Documents and Settings\poshoholic\My Documents\PowerShellRocks.ps1

The -noexit argument is a named switch property that is supported by PowerShell, so PowerShell knows to keep the console open when the script is done.  The remaining arguments aren’t associated with a named property, so PowerShell treats them as the command by concatenating them together with a space between the tokens.  This makes the PowerShell command look like this:

& C:\Documents and Settings\poshoholic\My Documents\PowerShellRocks.ps1

If you try to run this command in PowerShell, you will get an error because the parser doesn’t know what to do with the C:\Documents token.  Fortunately, the fix to this is simple.  As Ying pointed out, you can use single quotes instead of double quotes.  This means you could enter the command like this:

powershell -noexit & ‘C:\Documents and Settings\poshoholic\My Documents\PowerShellRocks.ps1’

In this case, the single quotes are not used to identify one argument to PowerShell.exe, so the argument list looks like this:

1. -noexit
2. &
3. ‘C:\Documents
4. and
5. Settings\poshoholic\My
6. Documents\PowerShellRocks.ps1′

Since the single quotes weren’t removed when the command was broken into tokens, the string remains intact when it is rebuilt as the command to execute within PowerShell.

But what if you really needed to use double quotes?  Well, double quotes work too, but you have to treat them as a special case because they are used to identify an argument that contains spaces.  More specifically, you have to escape them within a surrounding pair of quotes by entering two double quotes side by side.  In the case of our example, that means entering the command like this: 

powershell -noexit “& “”C:\Documents and Settings\poshoholic\My Documents\PowerShellRocks.ps1″””

Running this command results in two arguments being passed into PowerShell:

1. -noexit
2. & “C:\Documents and Settings\poshoholic\My Documents\PowerShellRocks.ps1”

Bingo, that’s the script that we originally intended to run!

While it might not be that common that someone wants to pass quotation marks into PowerShell via cmd.exe or Start | Run, I thought it would be useful to clarify this for whenever the need arises.  In general, I recommend always putting external quotation marks around the entire command that you want to pass into PowerShell this way and using paired double-quotes or non-paired single quotes within that quoted command as required.  This prevents unnecessary tokenizing and then rebuilding of the command which, as Ying’s article illustrated, doesn’t always rebuild as you would expect it to.

For related information, specifically pertaining to the order you need to use in your PowerShell.exe arguments, read this post.

Kirk out.

Technorati Tags: PowerShell, PoSh, Poshoholic
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |

I’ve recently started experimenting with PowerTab version 0.98 on one of my systems where I use PowerShell.  I hadn’t done this before for quite a few reasons:

1. I wanted to work with PowerShell 1.0 without modifications for at least the first little while to see how well it works by itself (suffice it to say that this is the best 1.0 release of a product I have used in a long time).
2. Beyond the initial experience with PowerShell 1.0, the built-in tab expansion was meeting my immediate needs when writing one-liners.
3. Whenever I would write anything more complex that a one-liner I would do so in an editor that had built-in syntax highlighting and/or intellisense (I say and/or because I’ve been trying out quite a few different script editors), and PowerTab wasn’t available within those editors.

But after listening to Scott Hanselman talk about PowerShell (and PowerTab) on a recent episode of .NET Rocks TV, I figured it was time I install this component that I’ve had sitting in my downloads folder since version 0.91 or so and kick the tires a bit.

While I haven’t used PowerTab for very long yet, so far I can say that PowerTab provides some really nice enhancements over the built-in tab expansion functionality, and if you’re working within the console that ships with PowerShell 1.0 it definitely helps, especially when working with WMI objects and .NET objects directly.  The visual browsing functionality it provides will be of greatest benefit to newcomers who don’t know their way around PowerShell, WMI and .NET yet.

That said, there are a few issues I have encountered in the current release, as well as some opportunities for enhancement requests that are worth mentioning.  First, the issues:

1. If you are viewing the tab expansion window for the current word and you press backspace or Esc, you can’t use tab expansion for that word from that point on.  For example, if you type in get-c, press tab, and then once you see your options you press backspace or Esc, tab completion will no longer work for get-c until you use tab expansion for something else.
2. If you are viewing the tab expansion window for the current word and you press backspace or Esc, you should be returned to the exact command you started with because you are cancelling out of the option to use tab expansion on that word.  This does not work properly for files or directories.  When you press backspace or Esc the word has changed.  For example, if I am in a folder with nothing but tab.txt and tabexpansion.txt, and I type in “t” and then press the Tab key, I see the two files.  If I then press backspace or Esc, the word I entered changes from “t” to the current working directory path with “\t” appended to it (prepended by “& ‘” and appended by “‘” if there is a space in the current working directory).

Now on to the enhancement requests: 

1. If you are viewing tab expansion options for a file or folder and you press backslash or space, that option should be selected and you should see your backslash or space in the command line.  This is necessary to prevent from additional keystrokes being required in the implementation of tab expansion (i.e. this is how it works in DOS and in PowerShell 1.0 when using the tab expansion routine that comes with PowerShell).  When you get to know what the minimum path is that you have to type, this can speed things up for you.  Having to press enter and then type the backslash is disruptive to how things worked before.  For example, using the tab expansion that comes with PowerShell, if I have two folders called “Tab” and “TabExpansion” and I know I want to navigate to the first folder I can type set-location C:\T, press the Tab key, and then press space or backslash depending on what I am doing and it will just continue.  If I do the same when using PowerTab it will beep at me when I press space, or it will do nothing when I press backslash.  I’d love to see this changed so that space and backslash will properly allow me to continue typing.  The same goes for files (although for files backslash doesn’t make sense, but space does).
2. Similar to the last one, if you are viewing tab expansion options for a .NET class and you press the right square bracket “]”, the current option should be selected and you should see your .NET class with the “]” character at the end in the command line.  Basically I think that if you press any character that is a valid terminator for the item that is showing in the tab expansion option list that the item should be terminated and you should see it with your terminator in the current line of script you are writing.
3. When you have a line of script on the screen and you activate tab expansion in the middle of that script, the remainder of that line of script is deleted.  This is an issue with tab expansion in the standard command prompt and the tab expansion that comes with PowerShell 1.0.  The impact of this issue is much more apparent in PowerShell when working with long one-liners (although you have command history so you can usually go back unless you just typed in a long one-liner from scratch).  I’d love to see this fixed with PowerTab, but I think this is beyond the control of what can be done in the TabExpansion function.

That’s about it for now.  I’ll continue experimenting with PowerTab and see what else I come across.  Kudos to Marc van Orsouw (MOW) for all of his hard work on PowerTab!  I look forward to seeing this functionality in PowerShell Plus!

Kirk out.

Technorati Tags: PowerShell, PoSh, Poshoholic, PowerTab, PowerShell Plus, Tab Expansion
Add to: | Technorati | Digg | del.icio.us | Yahoo | BlinkList | Spurl | reddit | Furl |