Monad cmdlet cleanup update
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.