I agree with supporting a familiar vocabulary using aliases, however I probably wouldn’t create them with a cmdlet-like “verb-noun” name format because I’d be afraid users would use those aliases in published and shared scripts and not just in ad-hoc work. In this specific case, I think the consistency provided through a small library of verbs which benefits the entire PowerShell community outweighs the benefits you’d be providing to scripters by using aliases to add verb substitutes for domain vocabulary familiarity. Learning that PowerShell has only a finite set of verbs and figuring out how to make intelligent guesses using synonyms once you learn some of those verbs is only a small hurdle to overcome. Otherwise, if one team uses Hold as an alias verb for Suspend and another uses Pause, and yet another uses Delay, or Retain, or something else, then we lose the benefits that a small set of verbs provides. Besides, there really is no notion of verbs in aliases as far as command metadata is concerned, so users wouldn’t be able to invoke Get-Command -Verb Hold to discover your alias commands, which could cause further confusion.

Even though I say all that though, I think aliases are great at retaining domain knowledge. Maybe not so much in the verb-noun format though. But I’m always open to discussion to see what possibilities do come out of it, and this is only my opinion on this issue. Food for thought anyway.

Kirk out.

For example, say a product’s users are accustomed to the notion of “holding” a job. “Hold” isn’t one of the PowerShell standard verbs, but “suspend” is.

In order to reconcile this, assuming the two-letter product abbreviation is “BE”, the ISV could export a cmdlet called Suspend-BEJob and an alias to the cmdlet called Hold-BEJob.

The result is that users benefit from the consistency and usability of both the PowerShell verbs AND product-specific terminology.

Consider imo/rmo for Import-/Remove-Module…those two save me personally a ton of time (they’re much less important in PowerShell v3 though). Or consider common ones like gsv (Get-Service), gps (Get-Process), or the breakpoint aliases: gbp, sbp, rbp, all very useful when defining command or variable breakpoints. They’re also useful for line breakpoints, but less since modern scripting environments make line breakpoints easy. If these aliases weren’t defined by default, I’d have to be diligent and organized enough to set up a profile, or a USB key if I work with multiple machines, plus consider RDP scenarios where a USB key wouldn’t be helpful. With those challenges in mind, I’m all for having some aliases defined by default…I just think module authors need to take it easy and stick to the most useful and most frequent commands for this.

The builtin aliases are ok in my opinion because they do serve as a way to ease the transition for users to PowerShell, e.x. dir or cd.

Let the user decide what they want shortened and create their own aliases.

I’d be interested in seeing usage counts that show how frequently the core aliases are used. Obviously the domain-specific ones are used the most, but others I suspect are hardly used at all, in which case why have aliases for those at all? You can tell by the core aliases that some were created simply because the developer and tester working on that set of commands wanted to have aliases for their simplified use, even when they aren’t really necessary in the real world (like the *-Alias commands — who needs aliases for Import-Alias and Export-Alias? I’d wager those aliases are hardly used at all.)

One additional possibility though, is to ship whatever aliases you like, but wrapped in code such that the user has to explicitly opt-in to exporting them:

Import-Module ModuleName -Argument ExportAliases

Dave C.

Regarding the version check, we will probably make it easier in future releases, but for now you can check the version of the installer exe (which is signed and has a version number), or you can simply invoke $host.Version from the embedded PowerShell console inside PowerSE or PowerWF.

If you have other questions or suggestions, don’t hesitate to share them!

Thanks,

Kirk out.

Love this IDE and so glad you are on the squad.

Quick question that’s always bugged me about it tho…How can I confirm that I’ve installed the latest version? There’s no help/about and the .exe doesn’t have a version on it either.

Thanks in advance sir!
-phil