Shell's TechBlabber

…ShelLuser blogs about stuff ;)

PowerShell; fun on the commandline

Many people with some roots into IT will know that it all started on a commandline. This holds true for nearly all major operating systems, and the ones which were quite early with hiding the commandline (OS/2 for example) still had their ‘ties’ into it.

Microsoft originally started with MS-DOS which was actually a rough ‘copy’ or ‘fork’ of CP/M (Computer Program / Monitor). Not a surprising development though; early high-end computers running on CP/M would sometimes also provide access to a ‘DOS mode’ thus allowing the unit to use both CP/M and DOS (I.C.L. used to produce such units).

But here things eventually stalled. When MS DOS 6 came out Microsoft started to focus more on the GUI aspect and left the commandline interface (“cli”) a little for what it was. At first users of 98 / XP had a full DOS 6 at their disposal but even that soon declined to a simple rather limited commandline shell.

Until 2007…

PowerShell 2.0

Although what I wrote above holds truth it didn’t mean that Microsoft had abandoned the CLI altogether, far from it. They were busy working on specific projects which eventually led to the release of PowerShell. The first commonly recognized version actually being v2.0 was shipped with Windows 7 and made available for previous versions of Windows as well; right up to XP and the server 2003 environment.

What is PowerShell ?

Now, this may look like a clichéd question but you’d be surprised how much people never came into contact with PowerShell before, even though it comes pre-installed with Windows 7 and Vista. It shouldn’t come as a surprise though since most people think about DOS, or the ‘black and white window’, when talking about the commandline or ‘command prompt’.

PowerShell is a commandline interface environment which is fully build on top of Microsoft’s .NET framework. Better yet; .NET is also fully integrated with the environment which allows you to use its features right on the commandline. And if you’re a little skilled with C#.NET or VB.NET you can pick up the freely available Visual Studio Express and use that to program extensions for PowerShell as well.

But I think the best parts about PowerShell is that its object oriented and fully tied into the Windows Remote Management API.

OO ?

“Object Orientation” or better put: Object-oriented Programming is something you’ll often come across when dealing with certain programming languages. It roughly means that the language allows you to build your programs as if all its components were individual objects. The advantage with that approach is that when done right all these objects can be easily re-used in other programs. To illustrate:

Say you wanted to program a calculator; then its design could be something like the diagram above. The whole rectangle represents “My Calculator” but the calculator itself consists of 4 modules or objects. One which handles user input, one which checks user input, a module to make the actual calculation and finally a module to display the end results to the user.

The main advantage here is that although you may approach a module as a single entity it can consist of a whole lot of programming code which makes it much easier to share it between different programs.

Everything is an object

When you’re working with PowerShell then you’re working with objects, no matter what you’re doing. An example:

Everyone who has worked with DOS before will recognize this; when you type ‘dir’ you get the contents of the current directory. Nothing special, right ? What is happening here is that using the command ‘dir’ invoked a program which read the contents of the current directory and showed them on the screen. But what more can you do with this information ?

Not much actually… You can feed it into another program such as sort which can then sort the stuff, you could re-direct the contents and save it into a file, and so on. But what if you’d want to pick out one single file and learn more about it ?  Windows 7 supports extended attributes such as creation date, modification date and can even track the owner of a file. Unfortunately for us DOS cannot cope with all that.

With PowerShell otoh. things work a little different:

Although it may look as if this dir command merely shows you an extended display of what you’re seeing above this couldn’t be further from the truth. As mentioned in the header: everything is an object, this includes directories or file(s) residing inside such a directory.

Do you remember what I mentioned above about the modules (or objects) in that calculator design?  While they represent a single entity they can actually consist of lots of programming code. The directory entries shown in PowerShell are no different:

You can click on the picture to see the full sized version.

So what is happening here?

I gave the command ‘Get-Item’ which really does just that; it gets me an item which I can specify on the commandline, in this case I chose for the ‘.’ (dot) item which represents the current directory.

Then I used the pipe character (‘|’) to send the output of the first command into another command; namely ‘Get-Member’. This command can get everything contained inside an object. So when I told it to get ‘*’ I basically told it to get (and display) everything inside the current directory object. You can see the results above; a whole list of Properties and Methods. And if you look at the names of some you’ll come across pretty familiar information such as: Name, Extension, CreationTime, LastWriteTime, and so on.

So how come we’re not seeing the CreationTime of the current directory ?

That’s because of the ‘Get-Member’ command; this shows me all the properties of the current object, but not its actual contents itself. If I wanted to see the actual object then I’d be using this:

Here we get to see everything about the item ‘.’, or put differently: the current directory. But as you can see we only see 4 items being displayed; the mode, the LastWriteTime its length and the name. But what about that huge list I showed you guys earlier?  Surely there must be more to it than this ?

And yes; there is. Here is where it can get a little confusing but its actually hardly as complex as it may look. Remember what I mentioned a few times now: “Everything is an object” ?

So what do you think ‘mode’, ‘name’ and ‘length’ are ?  These are the properties of the current directory, but these properties are just as much objects as the current directory itself is.

Display intelligence

Here you see a demonstration as to what I like to call “display intelligence”. Basically PowerShell will always analyse the data being processed and displays it best as possible so that you will always get a good overview.

So in case of a directory it chose to show you the most relevant parts; namely the name, the length and the last time it was accessed. But if you want to see more you’ll simply have to say so:

Here I select the current directory and then tell it to send this to the ‘select-object’ command. The * behind it instructs it to select all the objects available, and the result can be seen above. It shows you both the name as well as the contents of the objects.

Now, with the risk to make things even more complex…   You should expect as much by now: everything you see above are objects of their own which could have their own properties and methods. For example, lets take a closer look at the name:

Now you might start to wonder what good this all does you. Well, all this by itself is merely giving you a deeper example into objects and their members and to make you aware that everything in PowerShell is an object.

But to give an example of why this is quite useful to know…

Session Objects

In a next post I’ll be showing you some of the advantages you have when using PowerShell as an administration tool. But to give you a good example as to why objects are so important in PowerShell:

You can click on the picture to show the full version.

The first thing you see here is me showing you that I have 2 active sessions open with 2 remote Window servers. In the second command I’m starting a new command, and by specifying a specific session (or sessions in this case) this command basically instructs PowerShell to do all this on a remote computer.

Next there’s the ScriptBlock and here I’m specifying what command(s) I want to execute. As you can see I’m merely getting the item ‘C:\.’ which basically represents the root (main) directory of the C drive.

And as you can see the ‘display intelligence’ which I mentioned above suddenly kicks in as well. Not only does it show us the same 4 items as before (Mode, LastWriteTime, Length and Name) now it suddenly added a new entry named PSComputerName.

Because PowerShell noticed that I tried to execute 1 command on 2 different sessions it knew that the outcome of the command wouldn’t be enough for me to easily determine which session it came from. As such it decided to display that property as well.

Concluding

PowerShell is one of the reasons why I wanted to start a new more tech-based blog, and this post is the first start of a series devoted to PowerShell. While this was a rather easy post which covered some of the basics, next time I’m going to take a look at more advanced topics such as accessing your registry, and using WMI objects to perform certain admin tasks.

Advertisements

July 16, 2012 - Posted by | Editorial, Tips and tricks, Windows | , , , ,

Sorry, the comment form is closed at this time.

%d bloggers like this: