-Name in Get-XXX Cmdlets

-Name in Get-XXX Cmdlets

  • Comments 1

I just saw a cool article by Don Brown who has written a set of SMS Cmdlets for Windows PowerShell. These work with SMS 2003 and are well worth a look-see if you are an SMS customer. (Btw – I wrote Get-XXX to mean GET-(any nounname) but now that I look at it, it looks like a cmdlet to get hardcore porn – YIKES!! I can only guess at what the parameters to such a command would be. J ) While Don has published a relatively small set of initial cmdlets:

  • Disable-SoftwareDistribution
  • Enable-SoftwareDistribution
  • Get-CollectionMembers
  • Get-Collections
  • Get-SMSServerConnections
  • Verb-Noun    (Practice I guess)

It is a good start and may be something the community wants to create a community source project around at http://codeplex.com/ . (hint hint hint).

As I looked at the examples I saw a couple style things I would point out. First one should be obvious to all PowerShell users: Get-Collections/Get-ColllectionMembers. What are the chances that this is going to collide with something else in the future? Said another way, what are the chances that SMS is the only provider of "Collections"? Clearly this and all the other commands should follow the example of Get-SMSServerConnections and put SMS in the noun name.

I should point out a couple of things.

  1. As PowerShell, we'll use the characters "PS" in front of our noun names.
  2. We will use generic noun names whenever we provide an extension point. For example, in our V2 CTP, we have xxx-PSjobs. If we turn this into an extensible framework for interacting with JOBs from a variety of sources, we'll use the generic noun and rename these to xxx-JOBs.

The one example that really caused me to write this post was:

Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Disable-SoftwareDistribution

 

I've recently seen a number of cmdlets that do this pattern:

Get-XXX | where {$_.Name –match "xxx"

I'd like to assert that selecting things by name (or ID) is a rockbed concept of GET and as such:

  1. Get Cmdlets should support –NAME and/or –ID.
  2. This should be a positional parameter so that people don't have to specify –NAME. e.g.: Get-XXX xxxxx
  3. Naming should support wildcards. E.g. Get-XXX Win*systems

I know that this will cause developers to spend more time on their Get Cmdlets but the improvement in User Experience will make this a very worthwhile investment.

As a community of users – you should work with your vendors to stress these 2 points when you see their demos and try out their Betas. At the end of the day, your wallet has much more power than my blog. J

Let me also declare that PowerShell is not without blame on either of this points. Kenneth Hansen and I had dinner the other night and were bemoaning the fact that our Get-EventLog cmdlet did not support –Index (which is the ID of a particular event message). There are also a few examples where we should have used "PS" in our noun names and didn't. Apologizes for these shortcomings.

Don - thanks for this great article! I think you might have started something.

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx

 

Leave a Comment
  • Please add 5 and 4 and type the answer here:
  • Post
  • Seriously? "PS" in front of everything?  What about "discoverability"? What about tab completion? It seems to me that adding a common acronym to the front of every cmdlet is hardly going to guarantee uniqueness nor clarity in the discoverability: where I work, a "PsJob" is *always* a post-script print job.  

    Mostly, this tactic seems destined to force us to type longer and longer commands (when I make a PostScript job cmdlet, I'll have to call it Get-PostScriptJob or Get-XrxPsJob or something)

    Wouldn't it be better to just use the namespaces (which were, incidentally, created by programmers for the purpose of differentiating things)?  You could, after all, use shorter namespaces, or perhaps allow creating aliases for namespaces... That way, Microsoft.PowerShell.Core becomes PSCore or just PS or PSh, and Microsoft.PowerShell.Core\Get-PsJob becomes PS\Get-Job (the key is, even when it's not already shorter, you only need to type the namespace if you actually have a conflict, whereas if you put it in the Noun, you *always* have to type it (plus, then it's a noun phrase, and things start to get murky ... next thing you know you'll have to add syntax parsing for adjectives... ;)

    Seriously though: Get-SMSServerConnection could be SMS\Get-Server... (although personally, I'd go for MSSMS, so as not to confuse these SMS things with cmdlets for sending text messages to phones) ... since tab-completion could work on the snapin namespaces, typing even the full name would be abbreviated significantly.

    Well, that's my 2¢

Page 1 of 1 (1 items)