All your "man" pages belong to us.

I don’t want Carla Schroder to feel like I am throwing hand grenades over to her side of the fence (Linux), but I wanted to point out that PowerShell, the new command shell for Windows does in fact have some pretty good command-line accessible documentation that work in a very similar way to man pages.

With the command shell up all you need to do is type in “help”, and what you actually get back is an information page about how to use the help command, along with a few pages of examples:

The help system is pretty much tied to the various Cmdlet’s that the system has installed. The beauty of that is that you can ask for help for a list of the commands that it supports by typing “help *-*”:

The reason for this consistency is that PowerShell has all commands using a common verb-entity syntax. So if I want to bring up the help on a command - say Get-ChildItem, I would just type in “help get-childitem” and I would get several pages of help back.

Another cool feature is that it understands now to navigate aliases so if I asked for help on the gci command it would have returned the same result (because gci is an alias for Get-ChildItem, as is dir).

Let’s hope that PowerShell has command-line documentation for a long time to come!

Fun with scripting shells (how to rename multiple files in PowerShell).

I stumbled across this post by Rob Newcater on RootPrompt.org which points to this post on BasicallyTech.com. It shows the various ways that you can rename or manipulate filenames in groups using the bash shell and a smattering of standard UNIX utilities.

The sample given was renaming a directory full of *.mp3 files such that all the spaces were replaced with underscores - here is the script in BASH:

for FILE in *.mp3 ; do NEWFILE=`echo $FILE | sed ’s/ /_/g’` ; echo “$FILE will be renamed as $NEWFILE” ; done

That is pretty cool, although it is much more concise in PowerShell:

get-childitem *.mp3 | foreach { rename-item $_ $_.Name.Replace(” “, “_”) }

And by concise, I don’t mean shorter. One of the advantages of PowerShell over traditional text-piping shells is that you are dealing with objects which provide a lot more data to the next part of the processing pipeline. If you are into punctuation you could express it as:

gci *.mp3 | % { rename-item $_ $_.Name.Replace(” “, “_”) }

But to be honest, I prefer it the first way.

MGT304: PowerShell: Next Generation Command Line Scripting

Back when I was in high school I ran an after-hours bulletin board (you know, back when e-mail = FidoNet). Originally I ran the system on top of MS-DOS using the Maximus BBS package – it completely cracks me up that this software is still under active development and hosted up on SourceForge.

Eventually I migrated over to OS/2 which enabled me to run one line full time and an additional line after hours. Operating systems like OS/2 and DESQview were frequently used by BBS sysops because they were better at handling serial comms.

Of course, running a bulletin board involved more than just installing and configuring an operating system. Most bulletin board platforms like Maximus were really a framework upon which the sysop could build custom user interface and it was the process of taking groups of ASCII files and transforming them into the proprietary Maximus screen format (Mecca files). I would keep all of my ASCII files in a sub-directory and then after each change and do a batch conversion - the command that I issued looked something like the following:

for %f in (*.*) do build.bat %f

This would loop through each of the files that matched the filespec (*.*), and for each one call build.bat (a little batch file that I had strung together to do a couple of different things, including taking backups of existing files) – %f would contain the name of the file which is the subject of each loop.

Simple commands and scripts like this made my life a lot easier, and once I graduated from running a bulletin board to performing systems administration functions on computer networks I took my scripting skills with me.

Over the years I’ve used shells like bash, csh and ksh. I’ve also used Perl quite a bit. These shells give us quite bit of functionality and their use is considered a core skill for many UNIX system administrators. As dynamic languages like Python and Ruby get more popular in sysadmin circles, the boundaries of what is possible are being expanded – but where does this leave Windows system administrators?

The good news is that Microsoft has not been sitting idle and has been building a new command line and scripting environment for windows called PowerShell. In this session at Tech.Ed I’ll introduce PowerShell, look at what role it will plays in the future of platform administration on Windows.

What is the equivalent of the script above?

get-childitem | build

Of course, that assumes that I’ve got a function or cmdlet defined called “build”, but lets just pretend I do for now eh? See you in the session!

Aspen: PowerShell Futures

I just read the PowerShell blog and noticed that they are teasing us about the next release of the product and making sounds that it might have something to do with the next version of the Microsoft Management Console (note that the current version of MMC is 3.0). This is really a natural progression because if we look at some of the other management tools that Microsoft has shipped, the marriage of UI to underlying script generation is very useful for the system administrator community.

For example, pretty much every screen in the new SQL Server Management Studio (from SQL Server 2005) has the ability to product a script based on the current options on the screen. Ideally they could get to the same point that Apple has with their Automator tooling where scripting – even of the user interface components.

If every process declared its ability to be scripted then when you were doing a recording session the desktop compositing engine in Vista could somehow highlight those windows that could partipate in the process.

I suspect however that the Aspen release will be somewhat more limited in scope, and be more like the tooling from SQL. Still, I think it would be great fun to implement. If you are attending TechEd 2006 in Australia and would like to know more about PowerShell don’t forget to catch my session (MTG304) – it’ll be a must for system administrators responsible for managing Windows environments.