Partager via

Monad cmdlet cleanup update

  • Article

As Jeffrey mentioned in an earlier Blog “Finding which parameters are used the most” The Monad team is in the process of cleaning up our cmdlets to promote a more consistent user experience. The following two areas which we are focused on might have impact on you:

 

Cmdlet Verb names consistency and Parameters naming consistency.

 

Cmdlet Verb names consistency

 

The changes we are introducing might cause you to have to modify many of your existing scripts and possibly some code. Among the changes that will have direct effect on you are the cmdlet verb names changes which are as follows:

 

· Combine-Path will be renamed to Join-Path

· Parse-Path will be renamed to Split-Path

· Match-String will be renamed to Select-String

· Time-Expression will be renamed to Measure-Command

· Write-Object will be renamed to Write-Output

This change will ensure Monad core cmdlets conform with the verb naming guidelines described in the Monad SDK.

Parameters naming consistency

 

We are still in the process of implementing this cleanup phase and no concrete details are available as of yet to be publicly announced. The following shows a sample for some of the guidelines we will be using to complete this cleanup phase:

 

Issue

If a parameter has the same name across cmdlets, it should have the same type and semantics. You should use the same parameter name for the same concepts.

 

For example:

 

Match-String and Tee-Object cmdlets should use a –Path parameter aliased to MshPath instead of –FileName to have a consistent user experience across the different cmdlets.

 

Parameter names should be verbose and allow you to easily disambiguate them by simply typing the first three characters or using aliases. You only have to provide enough of a parameter name to disambiguate it but you can also use parameter aliases. We must use parameter aliases when parameters cannot be disambiguated easily using the first three characters.

 

For example:

 

-OutBuffer (-ob) and -OutVariable (-ov)

 

Both OutBuffer and OutVariable start with “out” which can only be disambiguated when more then the first three characters are used. The –ob and –ov parameter aliases resolve this issue

 

This posting is simply a heads-up on what will possibly be in the next release. Any thoughts or feedback is appreciated.

Comments

  • Anonymous
    February 07, 2006
    Hmmm, ya better be careful what you ask for.  :-)

    Most of the cmdlet name changes seem reasonable to me except Split-Path.  Based on my experience with String.Split, that names leads me to believe I will each path part output instead of just the one I selected.  In this case, I prefer Parse-Path.  I also like it because in the future I would like to see a Parse-Text cmdlet for slicing and dicing text.  

    One other thing, could the time-expression/measure-command functionality just be moved into Measure-Object using a different parameterset - one that takes a scriptblock?  Also it's a bit odd that Measure-Object is the one "utility" cmdlet that doesn't have a shorted alias.  You should consider aliasing Measure-Object to "Measure".

    BTW since you mentioned Tee-Object, it needs an -Append option for appending to a file instead of creating/overwriting.  :-)
  • Anonymous
    February 08, 2006
    Parameter Name Aliasing...
    That reminds me of the .NET show #43 on which both Jeff and Jim appeared.

    I hope you guys are not creating such parameters as "ProcessName" and "ProcessNames" in a same cmdlet :)

    Anyways, I am glad that you guys are going all out with naming convention which I think should be one of the most important characteristics to ease scripting.

    Well, parameter name aliasing has been such time saver in interactive mode.  But I think it is sometimes being abused in a way that some people post their MSH scripts using aliased parameter names degrading scripts readability.

    So will there be a way to actually "force" cmdlet users to use a "full" parameter name?(is there or will there be any .NET attribute or MSH flags[such as $FullParameterNamePreference]?)
  • Anonymous
    February 08, 2006
    What I'd like to see is an editor that:

    #1 provides the option to convert all names to either verbose or short alias format when a script is loaded.

    #2 provides the option to convert all short aliases to verbose format when the script is saved.

    In other words, I'd like the script "on disk" to always be in the verbose format, so if I ever send it to someone else, they can understand it; but I want my local display of the script to be configurable to use short aliases if that makes my life easier.
  • Anonymous
    February 09, 2006
    > So will there be a way to actually "force" cmdlet users to use a "full" parameter name?(is there or will there be any .NET attribute or MSH flags[such as $FullParameterNamePreference]?)

    You are spot on.  That said, "to ship is to choose" so not in V1.  We are looking at having a range of "STRICT" features in V2.

    jps
  • Anonymous
    February 09, 2006
    Oh I now understand the concept of this blog post.  Then, will the list of cleaned-up verbs and nouns be available for normal users to see? or is all the decision going to be decided internally by Monad dev'ers?

    I saw some list of verbs and noun names on newsgroup(microsoft.public.windows.server.scripting on January 5th, @ 2:01pm with title [MSH]<INPUT REQUESTED> Standard Verbs) about a month ago and i am wondering similar posting will be there for people to check out?
  • Anonymous
    February 09, 2006
    get-eventlog -newest

    OR

    get-eventlog -first


    should be -first to compatible with select-object cmdlet.
  • Anonymous
    April 01, 2006
    There's another aspect of naming that I occasionally see causing a problem: MSH cmdlets manipulating .NET objects typically use the .NET object's native name for parameters. In general, this is good glide path practice. However, for immediate shell use it occasionally produces awkward usages - for example, Get-Process has a -ProcessName parameter; comparing it to a few other cmdlets, though, it would make sense from a MSH-centered view for this to be just -Name.