In some recent training, I challenged the attendees to 'throw away' Cmd.EXE and to use the PowerShell console for everything. A good concept, but they challenged me back with: But what about all those commands I used to use – I can't use them any more, such as Ipconfig. That caused them some concern.
But: it turns out that Windows console applications run pretty much just fine under PowerShell. While I prefer using GIP than IPconcig, the later sure is a lot faster and I confess to using it when I just can't stand to wait GIP to finish up it's work. Its' great that these commands just work in PowerShell - just about every Windows Console application runs just fine, although there are some exceptions (and work arounds!).
The first exception is where PowerShell parses the command's parameters and recognises some characters in the command invocation as special PowerShell syntax, rather than the syntax of the command itself. For example, BCDEdit.exe used a Guid, enclosed in "{}" to represent different boot entries – PowerShell sees the guid as a script block , not as some text that can be parsed by the command and thus fails. Most of the misbehaving commands can easily be tamed by using the trick I showed in my blog article: http://tfl09.blogspot.co.uk/2012/08/taming-wild-console-applications-in.html – just use the –% characters as the first text after the cmdlet name (following by the rest of the command's normal parameters).
The other exception is that Interactive console applications are not supported from the PowerShell ISE. To get around this, just launch the console application using "Start-Process <console application>" command. This launches the application in a new windows.
Yet another reason to stop avoid learning PowerShell today!
0 Comments