Networking ... and naming stuff

Topics: Developer Forum
Jun 3, 2007 at 3:50 AM
Well, I finally got up some energy (and a tiny bit of time) to start looking at trying to add some stuff ... and I have a few questions.

I noticed there's practically no networking stuff in here (resolve-host, ping-host, and send-smtpmail) I wondered if that's because people have been using beta's of NetCmdlets? I mean, I know they have a bunch of really good stuff, but it's clearly not, well, you know ... free ;) So, my questions:

  1. Is there any reason not to duplicate cmdlets from commercial software.
  2. If not, when we do know we're duplicating effort should we:
    1. Imitate (their cmdlet names and interfaces (to the extent that we implement them)) to provide script compatibility
    2. Avoid conflicts by trying to use different names.

So, that said ... I posted a script a while back which I called Get-URL (it can download files over http or ftp) but as I've been using it, I started wishing for ... well ... progress reports while downloading. Doing so requires threading, and so, seems to require putting it in a cmdlet. Anyway, the .net WebClient can download both FTP and HTTP, so I figured to call it Get-Url or Get-UrlFile, but I noticed that NetCmdlets has separate cmdlets called get-http and get-ftp ... and thus, my questions.
Jun 5, 2007 at 6:34 AM
I think it is fine to provide cmdlets that may also appear in a commercial package. My main goal with PSCX was to provide a set of generally useful utilities to both admins and software developers. I would like to be able to say with confidence (at some point) that PowerShell plus PSCX provides equivalent functionality to cygwin or MKS Toolkit. We aren't there yet but that is the direction I would like to head. As far as naming goes, hmm, that's going to be a potential issue however folks will be able to disambiguate by using the snapin name pscx\ping-host.
Jun 18, 2007 at 2:52 AM
Edited Jun 18, 2007 at 2:53 AM
Regarding the naming issue, it appears that there are hints (from microsoft) towards naming cmdlets using a noun prefixed by the vendor name (or at least an abbreviation.) I think Quest already do this with their AD cmdlets, e.g. Get-QADUser.

The million dollar question: should we rename all of ours to Verb-PscxNoun for 1.2?
Jun 18, 2007 at 5:17 AM
If we change our cmdlets I would want something shorter like Verb-CxNoun e.g. Send-CxSmtpMail. We would need to consider the affects here because it would be a significant breaking change unless we create aliases (which introduces the old names again).
Jun 18, 2007 at 10:11 AM
I think renaming is a bad idea. For once, you'd need the back-compat aliases, which is duplicate effort for us (err, I mean you guys). Or you'd piss lot of people. And having these aliases, my guess is everybody would use the short aliases instead of the "real" names.
And you can use the Pscx\Ping-Host syntax, if there is a naming conflict.
Jun 18, 2007 at 4:10 PM
Yep that is my primary concern - breaking changes. We are starting to use PSCX in our automated test scripts. With 1.1's significant adoption I think we need to try very hard to avoid breaking changes from here on out. BTW what do you mean by "I mean you guys"? Have you retired from PSCX development or just gotten busy with other things (I know how that goes). :-)
Jun 19, 2007 at 1:07 AM
Edited Jun 19, 2007 at 1:10 AM
'Twas just a question I thought I should ask... personally, I wouldn't change either, but microsoft's ad-lib standardization attempts are getting steadier in direction. We no longer have verb "guidelines," but instead a finite number to use. They also allude to vendor prefixing; take this with the fact the script extension is versioned anyway (e.g. ps1), it looks like they are prepared to break stuff with vNext - perhaps we can revisit this then.
Jun 19, 2007 at 3:01 AM
If they introduce breaking changes to PowerShell then it would make it more palatable for us to do the same.
Jun 19, 2007 at 2:17 PM

rkeithhill wrote:
Have you retired from PSCX development or just gotten busy with other things (I know how that goes). :-)

retired? noooo way! but quite busy last few months :-((((
Jun 19, 2007 at 5:08 PM
<Verb>-<Vendor><Noun> is deffinitely not a good idea at all. Ever. For anyone. (Yeah, I feel that strongly about it). I haven't seen anything suggesting that from Microsoft, can I ask for a link?

The whole point of Verb-Noun is supposed to be consistency and discoverable naming conventions. If people go around sticking vendor names in the middle it completely defeats that -- now I'm forced to think about who wrote the stuff, instead of about what I want it to do! Now, while that might make Quest pleased as punch, since they're a commercial vendor, and have every incentive to make you think about them whenever you try to use their tools, I think we might as well just throw out the whole naming convention if I have to go through every stupid vendor's abbreviation looking for an implementation of Get-ActiveDirectoryUser ...

Honestly, when I started this thread, I started it only to ask if intentionally duplicating a command was a better idea than using what I considered to be a better noun. People seem way too worried about namespace conflicts -- after all, there's built-in differentiation via namespaces already: <vendor>\<verb>-<noun>. Quite frankly, we're working on applications that run in a command line interface* ... we shouldn't have to worry about "end users" getting confused, I think anyone who's willing to work on the command line can handle creating a few aliases ;-)
Jun 19, 2007 at 6:20 PM
Of course, what you say makes immeasurable sense, jaykul. But, I wasn't making it up when I said microsoft recommend the vendor prefix on the noun. From

Noun Names*


  • Commands should avoid using the noun names Windows PowerShell has reserved (See Section 3.3 Nouns).
  • Commands should use their product or feature name (or abbreviation) to prefix their noun.

This isn't really as outlandish as it sounds when you look at how other shells do things. When multiple groups create similar commands that must co-exist, the prefix is always the way things get resolved: cc/gcc, awk/gawk etc. Admittedly, the vendor\Verb-Noun system is better than Verb-(vendorAbbrev)Noun, but has it's own quirks in discoverability.

Jun 19, 2007 at 6:38 PM
I would suggest that perhaps it would be in the best interest of everyone if the commands themselves had a vendor/package prefix associated with them, but had aliases that did not. In this way you could have get-PscxFoo and Quest could have get-QFoo and MS could have get-PSFoo and you could either directly reference the package specific name, or an alias. Production Scripts should always use the command name (not aliases) where your one liners, day to day hackage could use the long name aliases or short name aliases.