semantics

The rule to write the names of cmdlets in the form - suggests some semantic implications on the particular task: if we have the cmdlet

    PS c:>get-psdrive 

    Name       Provider      Root
    ----       --------      ----
    A          FileSystem    A:
    Alias      Alias
    C          FileSystem    C:
    cert       Certificate   
    D          FileSystem    D:
    E          FileSystem    E:
    Env        Environment
    Function   Function
    HKCU       Registry      HKEY_CURRENT_USER
    HKLM       Registry      HKEY_LOCAL_MACHINE
    Variable   Variable

this implies as set of tripels

  < c >     < is a > < FileSystem >
  < env >   < is a > < Environment >
  < hklm >  < is a > < Registry >
  < alias > < is a > < Alias >
  …

Such tripels are the basic structure in the data model of the Resource Description Framework. Every such statement as above is called a tripel.
My question is now if there any useful application of this interpretation of cmdlet semantics?
Also piping could make sense in this picture:

  PS c:>get-process m*

might look like be

  Handles  NPM(K)    PM(K)      WS(K) VM(M)   CPU(s)     Id ProcessName
  -------  ------    -----      ----- -----   ------     --   -----------
       94        2     1032        1896    29     2,21    964   mdm
      189      129     1940        2524    40     1,46   2944   mqsvc
      118        3     1392        1428    34     0,25   3468   mqtgsvc
      159        6     1888        1292    36     1,26   1132   msdtc

If we pipe this thru to the get-command mdlet

  PS c:>get-process m* | get-command

this is

  CommandType     Name           Definition
  -----------     ----                ----------
  Application     mdm.exe           C:\WINDOWS\system32\mdm.exe
  Application     mqsvc.exe         C:\WINDOWS\system32\mqsvc.exe
  Application     mqtgsvc.exe       C:\WINDOWS\system32\mqtgsvc.exe
  Application     msdtc.exe         C:\WINDOWS\system32\msdtc.exe

this implies a typical graph of resources

  < handle : id=964 > < is a > < running process starting, name with m >
  < handle : id=964 > < is the programm >  < c :\WINDOWS\system32\mdm.exe >

Could it help to categorize items of the systems and relate them in such semantic graphs?
What is the difference to other shells ? They don’t have such a clear classification of commands (or cmdlets) in groups. In this case the result of

  PS c:>get-command get-*

should be the typical representant for such < is a > statement generators. Or tripelified

   < get-command get-* > < are > < "is a" generators >

(it’s late in the night, things getting weird, I should go to bed…

Further resources

Just as a presonel reminder another random collection of ´resources on powershell

• /\\/\\o\\/\\/ PowerShelled
• http://www.karlprosser.com/coder/?page_id=14
• http://www.tgdaily.com/2006/04/25/powershell_windows_command_line_to_ship_q4/
• microsoft.public.windows.server.scripting
• http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx
• WindowsPowerShellFaq
• Windows PowerShell Community Extensions

Sorry, it’s Powershell (PSH), but I really don’t like this name (Powersh..).

But let’s look at piping. What is piping ? In the UNIX world a typical piping command line looks like this

grep 'printf' main.cc | sort --unique | wc --lines 

then the piping symbol | handles only strings for output- input redicrection. In powershell it’s much more. piping is piping of objects. So something simple like

dir|format-list

gives something nice like

In this case the dir cmdlet outputs the directory object of the current directory. The piping redirects this to the input of the format-list cmdlet. In contrast to typical UNIX shell output you don’t have to know the concrete format of the output string. In fact in UNIX this example would be much more complex to realize (eg. using awk, perl or sed or other complex commands).

Another interesting, more questionable feature of PSH is that you may write window applications, ie. leave the usual command window and develop your own GUI with PSH. But why shouldn’t we do this in C# directly !! GUI programming was the target usage of the shell. The only graphic-like extension I know are curses or troff/groff.

But how does GUI programming work in PSH? As I mentioned in an earlier post PSH has C# as programming language base.
It can use the complete power of the .NET 2.0 framework. Let’s see

Windows.forms sample

Copy this sample code into a textfile, save the file, place it into the path and launch it form the PSH.

  [Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms")
  $form = new-object Windows.Forms.Form
  $form.text = "A Window label!"
  $form.dock = "fill"
  $button = new-object Windows.Forms.Button
  $button.text = "Click to exit!"
  $button.add_click({$form.close()})
  $form.controls.add($button)
  $form.showDialog()

You can see a form-filling button, defined to exit the application. But why should a scripting language have windows.forms?
Isn’t it a kind of contradiction?

Of course I think it’s nice, but perhaps as unnecessary as the TK extentions of several well known scripting languages (Perl, TCL). 99,9% of all tasks, successful scripting languages have to handle, are command line based tasks. The remaining 0,01% are not more than POC (proofs of concepts) far away from the complexity of compiled applocations.

Real world GUI apps are realized in C#, C++ or Java! The only exception scripting languages made their way into the GUI world, is directly in front of you, browser based applications!! (the usual mixture of HTML, CSS and Javascript)! But PSH is used in a different context. The main task of PSH is AUTOMATION. This paradigma has been promoted by all the key players of the Powershell developer team. But automation is diametral to GUI application, automatic applications have NUI (no user interaction). Perhaps the powershell developer group wants too much. Or perhaps they designed Powershell to replace HTA (Hypertext applications) used in Windows management in many ways. And such Hypertext applications always have graphical user interfaces. Of course from this point of view the decision to include classes such as windows.forms into PSH is consistent. Powershell will replace VBScript and JScript, the scripting languages behind HTA. Let’s see how PSH is going to evolve in the next years.

Powershell aka Monad

I wonder why the guys at Microsoft decided to alter the name of MONAD. MONAD aka Powershell ist the first real CLI (command line interface), developed by Microsoft from ground up.

A funny thing, after they changed the name to Powershell,… sorry, it sounds cheap!
But, ok the Microsoft marketing (or whatever) division probably didn’t like the connection to the Monadologie, the philosophical dream of Gottfried Wilhelm Leibniz. Wouldn’ it have been a great public relation coup to modify Leibniz well known iconic phrase of the best of all possible worlds into the best of all possible operating systems ?

Ok, forget it. It’s now Powershell. Like Powershampoo or Powerwoman…
A strange side effect of this name. Did you try a google search for powershell ? Today (22. May 2006) the first hit is the powershell project at sourceforge.net. It started in 2000, a UNIX / X11 terminal emulator and has absolutly nothing in common with the six years younger MS Powershell. Anyway….

What is it

Now for something completly different, the technology itself !
What are the core features of PSH (short for Powershell)

• It is a full .NET 2.0 application.
• It is a UNIX shell like application, to some point comparable to bash or zsh
• It won’t be an integral part of Windows Vista, but it can be run on Windows XP and Windows 2003 and will be integrated into Exchange Server 12 (shipped in 2007)
• PSH is a task-oriented automation framework
• PSH should (and will) replace VBscript and JScript, the former Microsoft scripting languages for Windows Administration
• basic commands are cmdlets (commandlets), which usually have the naming convention verb-noun such as Get-help, Get-WmiObject or Set-Acl .
• It can be extended using a C# interface

After you have downloaded, installed and launched the PSH , try a first command get-psdrive (a little bit annoying, PSH is case insensitive, so could also write Get-PSDrive ore even gEt-PsDRiveE). You get the something like

One would expect a list of all drives of the machine. But there is more. Note two interesting facts: first get-psdrive unifies several differnt information structures (registry , file system, environment) into a unique notion, in this case psdrives. Second there is a column provider. This is exactly what makes this unification possible.

Features and UNIX shells

PSH and UNIX shells have many features in common. A short list of terms and their UNIX shell counterpart (in fact I only know bash quite well and a little bit of ksh and csh).

• PSH aliases: Aliasing can be found in many shells, eg. bash
• PSH profiles: Every real UNIX shell has a hierachy of configuration scripts (system wide, user specific)
• PSH command substitution: constructs like
  $(dir c:\) are also possible in ksh
• PSH redirection, piping:Every shell has it
• PSH name completion:bash, tcsh, … can be configured this way

But this is to simple: PSH is a object oriented shell, none of the classical UNIX shells is such a shell. So in PSH a piping is a piping of objects and in bash it’s piping of text. It gives real great flexibility. Learn more about it at the video “monad demostrated” cited in the resources below.

Conclusion

My first impression says: Thanks, so I’ll forget vbscript hopefully quite soon. And let’s write UNIX flavored Windows administration scripts ! PSH will dramatically simplify tasks on Windows systems. The only bad thing is that PSH has only been established in the newest Microsoft products. So as long as Win2K is still used in productive environments, VBScript will be necessary.

Resources

Despite the fact that the development of PSH 1.0 has not been finished there are some interesting sources treating PSH.

1. An Introduction to: Microsoft Powershell, a free E-book published by realtimepublishers.com. It is a little bit outdated, because the author used Psh Beta 3.1
2. Introducing the MSH Command Shell and Language. A very first book, published by O’Reilly, which has the great advantadge that it uses PowerShell RC1 Update
3. Monad explained a Channel 9 video with Jeffrey Snover, the chief architect of the monad shell, explaining basic ideas on the automation aspect of monad.
4. Monad demonstrated a Channel 9 video with Jeffrey Snover, the chief architect of the monad shell showing some nice monad applications.
5. Monad at WinHec 2005: Slides, introducing some basic facts on MONAD shell(and of course also some propaganda)
6. Monad Wiki at Channel 9
7. Monad Blog at MSDN
8. Powershell Blog at MSDN
9. MSH Script repository at the Microsoft Scriptcenter
10. Monad Book by Don Jones and Jeffery Hicks: Windows PowerShell: TFM ( Chapter 1 [Draft Version] )