New CMDLET Noun Prefix

Topics: Developer Forum
Coordinator
Sep 16, 2007 at 5:29 AM
I have heard a number of complaints that it is hard to tell the PSCX cmdlets from the PowerShell cmdlets (kind of a compliment actually but it can cause problems). So I'm asking folks for their feedback on applying the following naming convention to new PSCX cmdlets:

  1. Push-CXEnvBlock
  2. Push-CxEnvBlock
  3. Push-PscxEnvBlock

Personally I like using just Cx cuz having to type Pscx seems like a bit too much. That is, if we were to do this. Thoughts?

Sep 17, 2007 at 5:34 AM
I don't really mind the names right now, but there is a good possibility of name collisions in the future. Especially as more and more people/groups/companies write scripts/cmdlets for Powershell. My preference would also be for something short like Cx.

If it is decided that PSCX switches to useing a Noun prefix, I would suggest creating an alias for the old name pointing to the new name. This would bypass most of the pain of changing object names for people with existing scripts. One note is that scripts would require 2 aliases be created. One with .ps1 and one without, since not everyone included the .ps1 and an alias only works with exact matches.
Developer
Sep 17, 2007 at 4:18 PM
This was here before. I would keep the old names; there is perfectly valid syntax for disambiguating snapins (Pscx\Push-EnvBlock), so I don't think we need to prefix our commands.
I would consider that on cmdlet basis, once there actually is a conflict with a Microsoft snapin (not so likely until Windows 7). When that happens, we'll have to consider what our version has to offer over the Microsoft's, and whether we should keep the command in the following versions.

The compatibility aliases take the worst from both approaches. You get 130 "back-compat-only" aliases, and distinguishing between PSCX and Microsoft command is as hard as before.

I think much better solution would be to provide an utility which would analyze a script and report whether it uses any of PSCX features. It could also automatically prepend the script with a "#requires -PSSnapin Pscx" statement and ensure it calls the required scripts/profile parts. (If we get so far, we could also rewrite the script to resolve aliases and prefix all Pscx commands with "Pscx\")
Developer
Sep 23, 2007 at 1:31 AM
My vote stands as before, changing Verb-Noun into Verb-VendorNoun completely destroys the whole concept of consistent naming and discoverability, and in my opinion, defeats the purpose of the Verb-Noun pattern. I mean, think about it, there's just no such thing as a CxClipboard ... it makes no sense to get or set it -- and if you could, people might legitimately think that you had created a special clipboard that wasn't the windows clipboard.

Plus, on top of the aliases already mentioned, don't forget that PowerShell automatically resolves Get-* .. so people can have scripts like:
 
$tmp = [IO.Path]::GetTempFilename()
Clipboard > $tmp  #note the missing Get-
Send-SmtpMail .... -AttachmentPaths $tmp
Developer
Sep 24, 2007 at 2:44 PM
jachymko said:

I think much better solution would be to provide an utility which would analyze a script and report whether it uses any of PSCX features. It could also automatically prepend the script with a "#requires -PSSnapin Pscx" statement and ensure it calls the required scripts/profile parts. (If we get so far, we could also rewrite the script to resolve aliases and prefix all Pscx commands with "Pscx\")


Agreed.
Sep 26, 2007 at 6:07 AM
Thinking about it I agree that changing to add the product in front of the noun will make it less intuitive and harder to use, but I still see problems with collisions. I think making it easier to trouble shoot collisions could be a help to the Powershell community as a whole. For example: if I do a “get-command man” I currently have both a man function and a man alias. If I had wanted the function to run first, it would have taken me a while to find this collision. By looking at the output, I’m still not sure which one is loading first, but I can see that there may be a problem.

If there were a command that was similar to Get-Command, but also included the run ordering, it would be easier to figure out.

Get-CommandRunOrder man
Name CmdType RunOrder
man Function 2
man Alias 1

With the RunOrder column I could see that I won’t ever run the function and just the alias. If the command would work with scripts, applications, cmdlets, and functions, it would make it easy to see collisions of any type without have to keep digging through different files, scripts, and paths. If it would even show where functions and aliases were declared it would make it even more useful (but even harder to write).

It gets even more complex if I have a script called man.ps1 in the execution path. If I execute “man” then the alias runs and not the scripts, but if I use man.ps1, then the script runs. But you can use scripts with or without the extension, so you have another possible point of collision. Same if you have an executable.

Get-CommandRunOrder man
Name CmdType RunOrder
man Function 2
man Alias 1
man.ps1 ExternalScript 3
man.exe Application 4

Ok, I’d better be done for now. Maybe someone has already done a command like this, but if so I haven’t been able to find it.