All About Interop : Powershell

More on PowerShell Interop - this time with Tibco EMS

DotNetInterop — Wed, 02 Jul 2008 17:04:00 GMT

Keeping on the theme of PowerShell interop....

Marc Adler wrote up a short, sweet little CmdLet for querying TIBCO EMS.

And he separately referenced a CmdLet by Scott Weinstein for connecting PowerShell to Coral8.

PowerShell CMDLets for WebSphere MQ - administer queues on Windows or Linux

DotNetInterop — Tue, 01 Jul 2008 00:27:00 GMT

Last year, I wrote about the idea of PowerShell CmdLets for WebSphere MQ. PowerShell is a beautiful scripting environment, you see, and it allows you to load any managed class library and then call into it. This is what allows me to, for example, create zip files within Powershell. But there are of course a zillion other possibilities. On the other hand if you are doing scripting, another opportunity for integration with PowerShell is CmdLets. CmdLets are little bits of function that get added to the Powershell base function. All the capabilities within PowerShell are exposed via commands that have a verb-noun structure, like Get-ChildItem. Or Write-Output. If you create a new cmdlet and add it to PowerShell , you've added to its vocabulary of functions. CmdLets offer better utility in a scripting environment, as compared to just loading an assembly and calling into the loaded class library.

It seems IBM have been busy doing CmdLets for MQ, and somehow this escaped my attention. Starting back in December 2007, Dale Lane at IBM published a series of posts about the topic of PowerShell CmdLets for MQ. There is also now an official SupportPac for this stuff, it goes by the catchy name of mo74. (direct FTP link here). In IBM-speak, a SupportPac is an add-on to the IBM product (in this case WMQ). Very good to see! Keep in mind that there are different categories of SupportPac and just because it says "support" in the name does not mean it is a "supported" part of the IBM product in the sense that you can call up their support engineers and ask for bugfix on it. mo74 is listed as Category 2, which means it is AS-IS software. SupportPacs can transition from "AS-IS" to a supported part of the product; this happens when customers demand it. Last updated April 16th, mo74 is currently at version 1.6.

One of the things you can do with the MQ cmdlets included in the mo74.zip SupportPac is administer queue managers on remote machines, including machines running MQ on Windows, Linux, or Unix. (If you know MQ, this shouldn't be too surprising, as you know that MQ can use the queue itself to send administrative commands.) IBM plans to add z/OS to the list of platforms that can be administered remotely using PowerShell. You can read about their plans and progress on integrating PowerShell with WMQ on the "Hursley on MQ" blog.

By the way, Dale also has a personal blog, where he writes about a bunch of stuff, some of which is related to PowerShell and WMQ.

It's good to see this integration.

Create Zip files within Powershell

DotNetInterop — Fri, 27 Jun 2008 00:54:00 GMT

You can use DotNetZip library from within Powershell. It's pretty simple, fast, easy.

example:

function ZipUp-Files ( $directory )
{

  $children = get-childitem -path $directory
  foreach ($o in $children) 
  {
    if ($o.Name -ne "TestResults" -and 
        $o.Name -ne "obj" -and 
        $o.Name -ne "bin" -and 
        $o.Name -ne "tfs" -and 
        $o.Name -ne "notused" -and 
        $o.Name -ne "Release")
    {
      if ($o.PSIsContainer)
      {
        ZipUp-Files ( $o.FullName )
      }
      else 
      {
        if ($o.Name -ne ".tfs-ignore" -and
           !$o.Name.EndsWith(".cache") -and
           !$o.Name.EndsWith(".zip") )
        {
          Write-output $o.FullName
          $e= $zipfile.AddFile($o.FullName)
        }
      }
    }
  }
}


[System.Reflection.Assembly]::LoadFrom("c:\\\bin\\Ionic.Utils.Zip.dll");

$zipfile =  new-object Ionic.Utils.Zip.ZipFile("zipsrc.zip");

ZipUp-Files "DotNetZip"

$zipfile.Save()

The example above shows how to create a zip. I use it to zip up a directory containing source files, and I leave out any unwanted files or directories. Of course you can also extract a zip, view a zip, Update a zip, and so on. Anything you can do in the DotNetZip library, you can do in Powershell.

Visit http://www.codeplex.com/DotNetZip to get DotNetZip.

C# Code Completion in emacs - getting beanshell equivalent in CSDE

DotNetInterop — Mon, 21 Apr 2008 19:56:00 GMT

The beanshell is something that, I think, was specially engineered to support the JDE, and particularly the code completion stuff. In JDEE, emacs starts up a Java VM and runs the beanshell class, in comint (command interpreter) mode. Then emacs can send commands to this beanshell thing, commands like "Tell me what you know about the class named 'foo'". And the beanshell reflects on foo and returns the result, which would include public methods and properties, and so on.

In my last post i said that the CSDE basically copied all this stuff over and did a search-and-replace (s/java/csharp). That's obviously not gonna work in general, and in particular with the beanshell. But we do have this Powershell thing in .NET land, don't we? Maybe you've heard of it. And I already put together a working powershell comint mode for emacs.

Just now I wrote a little TypeInfo class that exposes a single public static method, GetTypeInfo(). It uses reflection to list the members of a named class. I can load that TypeInfo() class into Powershell and interrogate types like this:

  [System.Reflection.Assembly]::LoadFrom("c:\\dinoch\\dev\\dotnet\\TypeInfo.dll");

  [Ionic.Reflection.Utilities.TypeInfo]::GetTypeInfo("System.Data.SqlClient.SqlCommand",
                                  "System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089");

  [Ionic.Reflection.Utilities.TypeInfo]::GetTypeInfo("System.Xml.XmlReader",
                                  "System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089");

  [Ionic.Reflection.Utilities.TypeInfo]::GetTypeInfo("System.DateTime",
                                  "mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089");

This is pretty much what beanshell does for JDE. Now to figure out how to return the information in the way that CSDE can use it.

I know, I know. I said I didn't want to write a code completion thing for C# in emacs. But the various building blocks are all just sitting there, ready to be stitched together. It's not far off.

[ Update: for the next installment in this drama, see the next post.]

Powershell script to batch-update AssemblyInfo.cs with new Version

DotNetInterop — Mon, 21 Apr 2008 18:15:00 GMT

I wrote this script to update all the AssemblyInfo.cs files in a Visual Studio solution, to have the same version number. This is the kind of thing I would have used Perl to do, in the past. But Powershell's got this covered nicely.

[ 23 April 2008 - 1150am PST - I updated the script to deal with the AssemblyInfo.vb files in a VB project, and also to deal with version numbers that have less than 4 digits. Thanks for the suggestion, Jason! ]

Maybe someone can learn from this.

# SetVersion.ps1
#
# Set the version in all the AssemblyInfo.cs or AssemblyInfo.vb files in any subdirectory.
#
# usage:  
#  from cmd.exe: 
#     powershell.exe SetVersion.ps1  2.8.3.0
# 
#  from powershell.exe prompt: 
#     .\SetVersion.ps1  2.8.3.0
#
# last saved Time-stamp: <Wednesday, April 23, 2008  11:46:40  (by dinoch)>
#


function Usage
{
  echo "Usage: ";
  echo "  from cmd.exe: ";
  echo "     powershell.exe SetVersion.ps1  2.8.3.0";
  echo " ";
  echo "  from powershell.exe prompt: ";
  echo "     .\SetVersion.ps1  2.8.3.0";
  echo " ";
}


function Update-SourceVersion
{
  Param ([string]$Version)
  $NewVersion = 'AssemblyVersion("' + $Version + '")';
  $NewFileVersion = 'AssemblyFileVersion("' + $Version + '")';

  foreach ($o in $input) 
  {
    Write-output $o.FullName
    $TmpFile = $o.FullName + ".tmp"

     get-content $o.FullName | 
        %{$_ -replace 'AssemblyVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', $NewVersion } |
        %{$_ -replace 'AssemblyFileVersion\("[0-9]+(\.([0-9]+|\*)){1,3}"\)', $NewFileVersion }  > $TmpFile

     move-item $TmpFile $o.FullName -force
  }
}


function Update-AllAssemblyInfoFiles ( $version )
{
  foreach ($file in "AssemblyInfo.cs", "AssemblyInfo.vb" ) 
  {
    get-childitem -recurse |? {$_.Name -eq $file} | Update-SourceVersion $version ;
  }
}


# validate arguments 
$r= [System.Text.RegularExpressions.Regex]::Match($args[0], "^[0-9]+(\.[0-9]+){1,3}$");

if ($r.Success)
{
  Update-AllAssemblyInfoFiles $args[0];
}
else
{
  echo " ";
  echo "Bad Input!"
  echo " ";
  Usage ;
}

WPF invokes Powershell.exe as an inferior shell

DotNetInterop — Fri, 11 Apr 2008 18:49:00 GMT

I wrote this up as an example of how to run powershell.exe as an inferior shell from within a WPF app.

It is not a "Powershell host" in the normal sense of the word, with a RunSpace and a RunSpaceFactory and so on. Instead, this example uses System.Diagnostics.Process to start powershell.exe as a process, and redirect stdin, stdout, and stderr. The result of those things is displayed in a WPF TextBlock.

The key bit is the Shell class, which I show here. It includes async i/o for the output.

    1 using System;
    2 using System.Collections.Generic;
    3 using System.Linq;
    4 using System.Text;
    5 
    6 namespace WPF_Host_for_PowerShell
    7 {
    8     class Shell
    9     {
   10         public delegate void OutputReceived(String output);
   11 
   12         private System.Diagnostics.Process _p;
   13         private System.AsyncCallback _rc = null;
   14         private System.IO.StreamWriter _sw;
   15 
   16         public System.IO.StreamWriter Input { get { return _sw; } }
   17         public OutputReceived StdoutOutputReceived { get; set; }
   18         public OutputReceived StderrOutputReceived { get; set; }
   19 
   20         public Shell(String exe, string args, OutputReceived callback1, OutputReceived callback2)
   21         {
   22             _rc = new System.AsyncCallback(ReadCompleted);
   23             StdoutOutputReceived = callback1;
   24             StderrOutputReceived = callback2;
   25             Launch(exe, args);
   26         }
   27 
   28 
   29         public class StreamState
   30         {
   31             public System.IO.Stream Stream;
   32             public byte[] Buffer;
   33             public OutputReceived Callback;
   34 
   35             public const int DefaultBufferSize = 2048;
   36 
   37             public StreamState(System.IO.Stream stream, OutputReceived callback)
   38             {
   39                 Buffer = new byte[DefaultBufferSize];
   40                 Stream = stream;
   41                 Callback = callback;
   42             }
   43         }
   44 
   45 
   46         private void ReadCompleted(System.IAsyncResult asyncResult)
   47         {
   48             StreamState state = (StreamState)asyncResult.AsyncState;
   49             int BytesRead = state.Stream.EndRead(asyncResult);
   50             if (BytesRead > 0)
   51             {
   52                 if (state.Callback != null)
   53                     state.Callback(System.Text.Encoding.ASCII.GetString(state.Buffer, 0, BytesRead));
   54 
   55                 System.Threading.Thread.Sleep(20);
   56                 // repeat: 
   57                 state.Stream.BeginRead(state.Buffer,
   58                     0,
   59                     state.Buffer.Length,
   60                     _rc,
   61                     state);
   62             }
   63 
   64         }
   65 
   66 
   67 
   68         private void KickoffAsyncReading(System.IO.Stream stream, OutputReceived callback)
   69         {
   70             // initialize the state for this async read loop: 
   71             StreamState state = new StreamState(stream, callback);
   72             System.Threading.Thread.Sleep(20);
   73             stream.BeginRead(state.Buffer,  // where to put the results
   74                 0,                          // offset
   75                 state.Buffer.Length,        // how many bytes (BUFFER_SIZE)
   76                 _rc,                        // ReadCompleted call back delegate
   77                 state);                    // local state object
   78         }
   79 
   80 
   81         private void Launch(string shellexe, string args)
   82         {
   83             _p = new System.Diagnostics.Process();
   84             _p.StartInfo.FileName = shellexe;
   85             _p.StartInfo.Arguments = args;
   86             _p.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
   87             _p.StartInfo.CreateNoWindow = true;
   88 
   89             _p.StartInfo.RedirectStandardOutput = true;
   90             _p.StartInfo.RedirectStandardError = true;
   91             _p.StartInfo.RedirectStandardInput = true;
   92             _p.StartInfo.UseShellExecute = false;  // required for redirect
   93 
   94             _p.Start();
   95 
   96             _sw = _p.StandardInput;
   97             KickoffAsyncReading(_p.StandardOutput.BaseStream, StdoutOutputReceived);
   98             KickoffAsyncReading(_p.StandardError.BaseStream, StderrOutputReceived);
   99         }
  100 
  101 
  102         public void Stop()
  103         {
  104             try
  105             {
  106                 _p.Kill();
  107             }
  108             catch { }
  109         }
  110     }
  111 }

To use it, it looks something like this:

    1 using System;
    2 using System.Collections.Generic;
    3 using System.Linq;
    4 using System.Text;
    5 using System.Windows;
    6 using System.Windows.Controls;
    7 using System.Windows.Data;
    8 using System.Windows.Documents;
    9 using System.Windows.Input;
   10 using System.Windows.Media;
   11 using System.Windows.Media.Imaging;
   12 using System.Windows.Navigation;
   13 using System.Windows.Shapes;
   14 
   15 namespace WPF_Host_for_PowerShell
   16 {
   17     /// <summary>
   18     /// Interaction logic for Window1.xaml
   19     /// </summary>
   20     public partial class Window1 : Window
   21     {
   22         delegate void MyAppendCallback(string s, System.Windows.Media.Brush color);
   23 
   24         Shell shell;
   25         TextBlock currentTextBlock= null;
   26         MyAppendCallback AppendDelegate = null;
   27 
   28         public Window1()
   29         {
   30             InitializeComponent();
   31 
   32             AppendDelegate= new MyAppendCallback(MyAppend);
   33         }
   34 
   35         private void MyAppend(string s, System.Windows.Media.Brush color)
   36         {
   37             if (this.Scroller1.Dispatcher.Thread != System.Threading.Thread.CurrentThread)
   38             {
   39                 this.Dispatcher.BeginInvoke
   40                     (System.Windows.Threading.DispatcherPriority.Normal, AppendDelegate, s, new object[] { color });
   41                 return;
   42             }
   43 
   44             lock (this.Scroller1)
   45             {
   46                 if (s != "")
   47                     this.currentTextBlock.Inlines.Add(new Run() { Text = s, Foreground = color });
   48 
   49                 this.Scroller1.ScrollToBottom();
   50             }
   51         }
   52 
   53         void StdoutReceived(string t)
   54         {
   55             MyAppend(t, System.Windows.Media.Brushes.BlueViolet);
   56         }
   57 
   58         void StderrReceived(string t)
   59         {
   60             MyAppend(t, System.Windows.Media.Brushes.Red);
   61         }
   62 
   63 
   64         private void Window_Loaded(object sender, RoutedEventArgs e)
   65         {
   66             // creating the shell starts it up
   67             shell = new Powershell(
   68                 new Shell.OutputReceived(StdoutReceived),
   69                 new Shell.OutputReceived(StderrReceived));
   70 
   71             InitCommand();
   72 
   73             shell.Input.WriteLine("prompt");
   74             shell.Input.Flush();
   75         }
   76 
   77         private void InitCommand()
   78         {
   79             // add a new textblock for each command
   80             currentTextBlock = new TextBlock();
   81             currentTextBlock.FontFamily = new FontFamily("Consolas");
   82             currentTextBlock.Margin = new Thickness(0d);
   83             //currentTextBlock.Foreground = color;
   84             this.OutputPanel.Children.Add(currentTextBlock);
   85         }
   86 
   87         private void Button_Click(object sender, RoutedEventArgs e)
   88         {
   89             InitCommand();
   90 
   91             MyAppend(this.textBox1.Text, System.Windows.Media.Brushes.SteelBlue);
   92             shell.Input.WriteLine(this.textBox1.Text);
   93 
   94             shell.Input.WriteLine("prompt");
   95             shell.Input.Flush();
   96         }
   97 
   98         private void Window_Closing(object sender, System.ComponentModel.CancelEventArgs e)
   99         {
  100             shell.Stop();
  101         }
  102     }
  103 }

The full source is attached. Maybe interesting and re-usable for someone who wants to embed Powershell capability into an application.

PowerShell in Emacs, proof!

DotNetInterop — Fri, 11 Apr 2008 07:51:00 GMT

Here's the proof that you can run powershell as a shell in Emacs.

Grab the download from yesterday to get this awesome power yourself!

Run PowerShell as a shell within Emacs

DotNetInterop — Thu, 10 Apr 2008 22:46:00 GMT

I saw a couple people asking about running powershell as an inferior shell within emacs. Here's what I do.

For the tragically unhip, some background: PowerShell is a nifty shell, it ships as an add-on to Windows. Currently at v1.0, but the v2.0 is available as a CTP. Emacs is the venerable supereditor that does 1001 things - one of those things is the ability to run a shell within a buffer. Emacs runs on Unix and Windows, and the shell stuff is configurable across a wide variety of shells and operating systems. As I was saying, some people have expressed interest in running PowerShell as an inferior shell within Emacs.

We're not talking about a powershell script editing mode. That problem has been solved. Instead, we're talking about running a powershell interactively within emacs.

There are a couple challenges with doing this. First, emacs is complex, and it is hard for people to figure out to do what they want. Even the doc is impenetrable. Basically you just have to KNOW how to do something, or someone else shows you. Getting back to our situation, to explicitly specify the shell to run, in emacs you set a variable called explicit-shell-file-name. Great, so we set this to c:\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe. There's an example for starting shells that says "to set the arguments to the shell, set the explicit-sh-args variable. People were setting this variable and trying to run PowerShell but getting an error. That's because the variable name for arguments is different for each shell. For bash, sh is the image and the variable is explicit-sh-args. For powershell, the variable to set is explicit-powershell.exe-args . Of course! This isn't explicitly documented anywhere (that I could see), but if you read the source code for shell.el you will see it. And, to further complicate things, if you don't explicitly set anything in that args variable, shell.el implicitly includes -i as an argument, which makes powershell barf. -i is a valid powershell argument, but it needs another param. Hence the barf. Anyway, to avoid all this, set explicit-powershell.exe-args . Example:

  (setq explicit-shell-file-name "c:\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe")
  (setq explicit-powershell.exe-args '("-Command" "-" )) ; interactive, but no command prompt

After setting these variables, to launch powershell from within emacs, just use M-x shell. This gets you to the second problem: powershell goes into "noninteractive mode". It emits no prompts, although it reads from the stdin and puts output on stdout. So you can see the input and output, but no prompts at all. Needless to say, it's a bit unfriendly to do this.

To fix this up we have to ask powershell to give us prompts. A simple thing to do would be to launch powershell in interactive mode, despite the fact that stdin and stdout have been redirected. There's an option on powershell.exe to launch it in "noninteractive mode" which means no prompts, and which is already what we have. We want the converse. I couldn't figure a way to do the "force interactive mode", so I used some emacs lisp to sort of fake it.

Within shell mode, there are "hooks" that emacs will call, on certain events, and overrides that you can set. (Sort of like the channel stack in WCF.) One possible override is the "send command to shell" method. You can write some custom code that runs, every time the user types in a command to the shell, in order to send the command to the shell. You can filter it, modify it, log it, suppress it, whatever. I wrote a simple wrapper in elisp that sends the original command, and then ALSO sends the "prompt" command. This causes powershell to emit the prompt, after the first, explicit command is run. Cool. That's what we want.

Then there are some rough edges. For example, powershell assumes an 80-character width for a terminal in non-interactive mode. You can set this by tickling the RawUI object within powershell itself. This is made possible with another hook. Also, I need to resize the powershell terminal whenever the emacs window changes. So I need to hook the window-size-change event within emacs.

One last thing is that the powershell prompt comes out with a trailing newline. So I need to trim that off as well, so that the next command you type in the powershell inferior shell, is just to the right of the powershell prompt.

Anyway, the result is the brief bit of elisp attached here. It's pretty bare-bones, but it's a start. And it lets you do what you want - run powershell as an inferior shell within emacs.

;; powershell.el, version 0.1
;;
;; Author: Dino Chiesa
;; Thu, 10 Apr 2008  11:10
;;
;; Run Windows PowerShell v1.0 as an inferior shell within emacs. Tested with emacs v22.2.
;;
;; TODO:
;;  test what happens when you expand the window size beyond the maxWindowWidth for the RawUI
;;  make everything configurable (Powershell exe, initial args, powershell prompt regexp)
;;  implement powershell launch hooks
;;  prevent backspace from deleting the powershell prompt? (do other shells do this?)
;;

(require 'shell)


(defun powershell-gen-window-width-string ()
  (concat  "$a = (Get-Host).UI.RawUI\n" 
            "$b = $a.WindowSize\n"
            "$b.Width = " (number-to-string  (window-width)) "\n"
            "$a.BufferSize = $b\n"
            "$a.WindowSize = $b")
  )
  

(defvar powershell-prompt-pattern  "PS [^#$%>]+>" 
  "Regexp for powershell prompt.  This isn't really used, because I couldn't figure out how to get it to work."
  )

(defgroup powershell nil
  "Running shell from within Emacs buffers."
  :group 'processes
  )


(defcustom powershell-need-rawui-resize t
  "set when powershell needs to be resized"
  :group 'powershell
)

;;;###autoload
(defun powershell (&optional buffer)
  "Run an inferior powershell, by invoking the shell function. See the help for shell for more details.
\(Type \\[describe-mode] in the shell buffer for a list of commands.)"
  (interactive
   (list
    (and current-prefix-arg
         (read-buffer "Shell buffer: "
                      (generate-new-buffer-name "*PowerShell*")))))
  ; get a name for the buffer
  (setq buffer (get-buffer-create (or buffer "*PowerShell*")))

  (let (
        (tmp-shellfile explicit-shell-file-name)
        )
                                        ; set arguments for the powershell exe.
                                        ; This needs to be tunable.
    (setq explicit-shell-file-name "c:\\windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe")  
    (setq explicit-powershell.exe-args '("-Command" "-" )) ; interactive, but no command prompt
  
                                        ; launch the shell
    (shell buffer)

    ; restore the original shell
    (if explicit-shell-file-name
        (setq explicit-shell-file-name tmp-shellfile)
      )
    )
  
  (let (
        (proc (get-buffer-process buffer))
        )
    
    ; This sets up the powershell RawUI screen width. By default,
    ; the powershell v1.0 assumes terminal width of 80 chars.
    ;This means input gets wrapped at the 80th column.  We reset the
    ; width of the PS terminal to the window width. 
    (add-hook 'window-size-change-functions 'powershell-window-size-changed)

    (powershell-window-size-changed)
    
    ; ask for initial prompt
    (comint-simple-send proc "prompt")
    )

  ; hook the kill-buffer action so we can kill the inferior process?
  (add-hook 'kill-buffer-hook 'powershell-delete-process)

  ; wrap the comint-input-sender with a PS version
  ; must do this after launching the shell! 
  (make-local-variable 'comint-input-sender)
  (setq comint-input-sender 'powershell-simple-send)

  ; set a preoutput filter for powershell.  This will trim newlines after the prompt.
  (add-hook 'comint-preoutput-filter-functions 'powershell-preoutput-filter-for-prompt)

  ;(run-hooks 'powershell-launch-hook)

  ; return the buffer created
  buffer
)


(defun powershell-window-size-changed (&optional frame)
  ; do not actually resize here. instead just set a flag.
  (setq powershell-need-rawui-resize t)
)



(defun powershell-delete-process (&optional proc)
  (or proc
      (setq proc (get-buffer-process (current-buffer))))
  (and (processp proc)
       (delete-process proc))
  )



;; This function trims the newline from the prompt that we
;; get back from powershell.  It is set into the preoutput
;; filters, so the newline is trimmed before being put into
;; the output buffer.
(defun powershell-preoutput-filter-for-prompt (string)
   (if
       ; not sure why, but I have not succeeded in using a variable here???  
       ;(string-match  powershell-prompt-pattern  string)

       (string-match  "PS [^#$%>]+>" string)
       (substring string 0 -1)
     
     string

     )
   )



(defun powershell-simple-send (proc string)
  "Override of the comint-simple-send function, specific for powershell.
This just sends STRING, plus the prompt command. Normally powershell is in
noninteractive model when run as an inferior shell with stdin/stdout
redirected, which is the case when running as a shell within emacs.
This function insures we get and display the prompt. "
  ; resize if necessary. We do this by sending a resize string to the shell,
  ; before sending the actual command to the shell. 
  (if powershell-need-rawui-resize
      (and
       (comint-simple-send proc (powershell-gen-window-width-string))
       (setq powershell-need-rawui-resize nil)
       )
    )
  (comint-simple-send proc string)
  (comint-simple-send proc "prompt")
)

To use it, you need to add in this text in your .emacs file:

(autoload 'powershell "powershell" "Run powershell as a shell within emacs." t)

Start powershell within emacs with M-x powershell. You can continue to use the regular Windows shell within emacs via M-x shell.

Cheers!

IBM's new MQ Blog includes some good .NET stuff

DotNetInterop — Fri, 16 Feb 2007 20:51:00 GMT

The MQ Engineers at IBM’s Hursley Lab (near Winchester, England) now have a blog. (By the way, the Hursley campus is just gorgeous.)

The blog is pretty new, started only last month, as far as I can tell, but it is already chock-full of interesting, high-content posts. I learned about it when Saket Rungta of IBM sent me an email.

I want to call your attention to a couple of entries in particular.

· “the Simplest MQ Publish/Subscribe Ever”, this one features IronPython, and XMS.NET.

The author shows how to build a publisher and a subscriber, in python running on .NET. The app uses the XMS.NET library to connect to the MQ Resource. Nifty!

http://hursleyonwmq.wordpress.com/2007/02/13/simplest-websphere-mq-publishsubscribeever/

· “WebSphere MQ Scripting using PowerShell”

http://hursleyonwmq.wordpress.com/2007/02/12/websphere-mq-scripting-using-powershell/

This is pretty cool. See, here's the thing about Powershell - it is a .NET-enabled scripting environment, so if you have a .NET class library (Such as IBM's MQ Classes for .NET), you can do pretty much anything that is enabled by that class library. Which means, from the script you can create queues, clear queues, delete queues, and so on. Anything you can do from the class library.

One editorial comment: One of the ideas embraced by PowerShell is that APIs are not the right level of abstraction for Administrators. PowerShell introduces the ideas of "Cmdlets" and "functions" - very small pieces of code focused on delivering the right user experience to admins and other people who would use scripts. It would be cool to have a powershell library for MQ - something with the right level of verb-noun abstractions. I imagine it would be a pretty thin layer. It's on my increasingly long list of things to investigate.

Kudos to IBM for the new blog!