Grab bag - Cygwin SSH and Zombie bash processes on Windows and PowerShell symbols

June 3rd at 12:00am

Sometimes I find a lot of little things that are worth remembering but aren't worth making a whole article about. In Today's Grab Bag we have:

  • Powershell null, true and false symbols
  • Cygwin SSH + Bash zombie processes on Windows
  • 'Dynamic' casting in C#.NET

Powershell null, true and false symbols

For some reason Microsoft just couldn't leave these basic symbols alone. If you try to use null, true or false in a PowerShell Script you will find it doesn't behave how you expect. To get the expecte behavior you have to pre-pend a $ (Dollar sign) so they become:

  • $null
  • $true
  • $false
The Variable notation for these symbols just seems 'wrong' to me.

 

Cygwin SSH + Bash zombie processes on Windows

While expanding my automation efforts I noticed that some of my windows systems running CYGWIN SSH Server + Bash would become unresponsive after after a few minutes of running automated tests. After some investigation, I found that bash.exe was hanging after I 'closed' my SSH Connection. When looking in the Windows Task Manager I found 63 instances of bash.exe (or was it 64 instances? Been a couple of weeks since I saw this last...).

I can work-around the problem by killing all bash processes, but that is NOT a good solution. Many of the systems I run automation on are shared boxes where other bash sessions are active. Since the automation runs as root (Administrator on Windows), killing bash processes would kill everyone's running bash shells.

A little more investigation turned up a nifty feature of the bash shell which mitigates this problem: Built-in timed logout! Now when I run my automated bash scripts I pre-pend this line to my script:

export TMOUT=100

The TMOUT variable tells bash to quit in 'x' seconds if there is no activity. I've set mine to a little under 2 minutes in this example, which is more than enough buffer for my needs. With this set I can be assured that bash.exe processes won't build up even if one is left 'hanging' since it will clean itself up once the timeout value elapses.

 

'Dynamic' casting in C#.NET

In more complex projects where I want to minimize code duplication I typically turn to Generic types with a sprinkling of Reflection. While normally 'good enough' there are occasions where I need to perform a dynamic type conversion. This can be accomplished in C#.NET like this (Example is taken from a custom-object constructor I put together awhile back):
 

PropertyInfo[] props = this.GetType().GetProperties();

// Some code that starts a loop to populate the various properties of the object instance

props[i].SetValue(this, Convert.ChangeType(objInput, props[i].PropertyType), null);


The last line is where the magic happens. Inside a loop I process the constructor parameters that correspond to each object property. Given the generic nature of the inputs (Object type) I want to convert the Object to the correct type before setting the Property value. Here's a breakdown of what is happening:

  1. Convert.ChangeType is fed the input object and the object type I want to convert it to.
    1. In this example I pull the desired type from the property I'll be setting (Using the PropertyType property of the PropertyInfo type [that's a mouthful!]). This makes the loop nice and generic which lets me avoid setting each property manually
       
  2. The SetValue method is called to set a specific property on a specific instance of the object type.
    1. The specific instance is set to the current object using the this statement

 

Here's the Convert call isolated from the rest of my case-specific code:

Convert.ChangeType(objInput, outputType)


References: