Five enhancements that PowerShell really needs
Summary: PowerShell is one of the best Windows tools available, but it could be even better. Here are my five suggestions for a better PowerShell experience.
PowerShell is Microsoft's scripting language, now in its third iteration. It's an extremely powerful tool to use for automation work, system administration, working remotely on systems, or working on multiple systems at a time. You can use it interactively or in a script. You can also touch multiple systems in a script by using its handy looping mechanism. So what more could one possibly want out of PowerShell that it doesn't already do? Plenty.
OK, first, PowerShell is a modular language, so that's one major point in its favor. Why? Because modularity allows it to be extended "voluntarily". By voluntarily, I mean that it can be extended by adding modules instead of having everything already packed in with no possibility of extension.
PowerShell 3.0 was a huge extension over PowerShell 2.0. PowerShell 3.0 comes equipped with thousands of cmdlets for almost every purpose — almost. And that's where this post begins — where PowerShell 3.0 leaves off.
Here is a list of what I think PowerShell 3.0 still needs:
-
*nix Connectivity Utilities — Boldly missing are tools for *nix style connectivity, such as SSH, SCP, SFTP, and others. There are some third-party modules for this, but they aren't very good, although I've had some success with SSHSession
-
Backup/Restore Support — It would be nice to have some deep dive Backup and Restore tools in PowerShell, and enhanced versions of command line utilities such as AT and NTBACKUP
-
Better Output Support — PowerShell has -OutFile and -ExportCSV output redirection, but you can't always get what you need from one of these because some output can't be redirected. For some output, you can do the following:
PS> script.ps1 > file.txt and then use the text file. However, there are times when that sort of "out of script" redirection doesn't work for output either. You should see some of the crazy ways I've had to grab output from scripts. I'd really like to see better output redirection. In other words, anything that I can output to the screen (STDOUT), I'd really like to see supported in -OutFile or -ExportCSV, or some other redirection option -
Import on First Use — Rather than import Microsoft-branded modules, such as Active Directory modules, you should be able to download and install them on first use like you do with some of Microsoft's other features. This would be a very handy feature so that, for example, I could run a Get-ADUser on a system, and PowerShell would import the module and run the cmdlet without interaction from me
-
Easier to Extract and Format Info — You can extract a lot of good information using PowerShell, but then to actually get the data you want into a desirable (readable) format, is very difficult. For example, PS> Get-Process provides you with a list of processes from your system in table format as shown in Figure 1.
Figure 1: Partial Process List — PowerShell. (Image: Screenshot by Ken Hess/ZDNet)
Now, try to just list the Process ID and ProcessName with PS> Get-Process | FT ID,ProcessName
See the result in Figure 2.
Figure 2: Processes Filtered by ID and ProcessName. (Image: Screenshot by Ken Hess/ZDNet)
Do you see the problem? Now you might think that this isn't a problem because you can either live with the odd original location format or you can direct it to a text file. Wrong. When you direct the output to a text file, you get a text file with the columns pushed out to the right, just like they are on screen.
Forget about Format-Wide; it doesn't work. Format-List is even uglier than Format-Table. And if you said, "Try Format-Custom"; it's worse than the others, although I think that you can create a custom view (an XML file) and use that for a better format. But seriously, that's a lot of trouble for a simple list of IDs and process names.
If this were a *nix environment, I'd do something like this to get the format I want:
$ ps -ef | gawk -F" " '{print $2,$8}'
To yield,
PID CMD
1 /sbin/init
2 [kthreadd]
3 [migration/0]
4 [ksoftirqd/0]
5 [watchdog/0]
6 [migration/1]
7 [ksoftirqd/1]
And in fact, what I would do on my Windows systems, since I have CygWin tools installed and in my path on my automation systems, is:
PS> Get-Process |gawk -F" " '{print $7,$8}'
To yield,
Id ProcessName
-- -----------
3780 AmIcoSinglun64
1788 AppleMobileDeviceService
4900 ApplePhotoStreams
5396 APSDaemon
1764 armsvc
3844 atieclxx
948 atiesrxx
1444 AvastSvc
5188 AvastUI
I shouldn't have to resort to such measures to get what I need in terms of formatting. If you know of a better way, I would love to see it. So far, I haven't found one, though I've looked for a solution.
OK, that was a really, really long number five, but sometimes, it helps to fully illustrate a point to drive it home.
[Update: one of my readers has supplied a fix for this problem with the -Autosize switch. If this works for all such formatting, then I guess we can mark number five off the list. Thanks.]
These are my five enhancements to PowerShell that I'd like to see. Do you have any improvements that you want included in a PowerShell update? Talk back and let me know.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
fix for number 5
get-process | ft -autosize id, processname
BAM!
forgot to include the link
Try and manipulate the objects in pipeline before exporting or displaying
get-process|select-object id, processname|Export-Csv test1.csv
For backup, if you are using the latest system center then everything should be available in PowerShell including backup with DPM.
Thanks,
PS is certainly NOT that bad!
@lawryll
"thousands of cmdlets for almost every purpose"
Anytime something requires more than about 300 "commandlets" to be useful is pretty will guaranteed not to be that useful.
Everybody will be recreating them because they can't find the right one(s) to use, and likely can't be used in combination.
Yet it is extremely easy to not only find the right one
Decouple Command Interpreter From GUI
Windows simply does not grasp the full power of the command line. No wonder Windows users, even seemingly knowledgeable ones, think it is something to be feared.
As someone
Knowledgeable Windows users have no fear for the command line whatsoever, and there isn''t any need. Running commands on remote systems do not require wmi, you are mixing things up here. powershell is using winrm which is just as simple as enabling ssh on unix like systems.
Re: powershell is using winrm
Those who only know Windows just seem incapable of appreciating this.
What is wrong with winrm I wonder ?
I probably have more years under my belt on Unix and Linux that you, I certainly know Windows, something you obviously know next to nothing about..
Re: What is wrong with winrm I wonder ?
Decent syntax
When I was writing my first powershell script I spent whole day looking for simplest things that I have done many times before using other tools. Yes I learned powershell but I felt like I learned just another useless variation of batch syntax.
5 enhancements and not one of them valid
1. *nix Connectivity Utilities – Already present (WinRM & PowerShell remoting)
2. Backup/Restore Support – Already present. http://technet.microsoft.com/en-us/library/ee706683.aspx
Now please do not go asking for PowerShell to do more than the OS can actually do, NTBACKUP is not available in any Windows version after XP or 2003. From what I see most (if not all) backup features included in Windows 2008 (should be the same for Win 7) are covered. If you are talking about Windows 8, I have not checked but I suppose file history feature are implemented in PS.
For the at command:
help ScheduledJob
3. Better Output Support – I don’t understand what the author exactly means, as I don’t know why he had to use the crazy ways to grab output. However I think once he gets a better understanding of what will be redirected and what will not, things will be much more easier . http://connect.microsoft.com/PowerShell/feedback/details/297055/capture-warning-verbose-debug-and-host-output-via-alternate-streams
4. Import on First Use – I will have to agree on this, but just a bit. For my servers I would rather suggest depending on what roles / features are installed and being used, the modules should be automatically installed and imported on boot up; it may slow the boot time by a few seconds, but then again I’m not expecting my server to complete booting within 1 minute or so. For the client machines, I will agree with this point. However this is more a matter of individual choice.
5. Easier to Extract and Format Info – Can be done using a simple switch as already pointed out.
Re: 5 enhancements and not one of them valid
2. PowerShell and Windows lack anything to compare with the power of rsync on *nix.
3. Probably he is talking about the fundamental Windows limitation that prevents treating all file handles as the same.
Re: 5 enhancements and not one of them valid
stillsjaak327 has already addressed this above and I will not repeat it.
2. PowerShell and Windows lack anything to compare with the power of rsync on *nix.
Did the author mention anything about rsync?
The way I see it rsync is an additional application that can be installed. But again there are other applications for Windows which can be installed and managed using PS, like DPM.
3. Probably he is talking about the fundamental Windows limitation that prevents treating all file handles as the same.
Maybe; or maybe he does not know PS well enough, to be able to suggest meaningful enhancements for it.
Re: Re: 5 enhancements and not one of them valid
2. He mentioned backup. rsync is the most powerful and versatile backup/bulk transfer utility around.
3. Given the Windows limitation is real, that's most likely what he was referring to.