Windows PowerShell Blog

PingBack from http://www.anith.com/?p=31630

There's a clear asymmetry in that for "New" (which in any case is an adjective, rather than a verb) there is no corresponding "Delete".

   * Delete

   * Opposite of 'New'

   * Common

   * For something free-standing (not obviously in an Add/Remove model) that can be created ("New") and managed directly, an explicit way of getting rid of it, including existing items like Alias and Service (at least) also general items like -- document, database, hierarchy

   * The least-worst match is "Remove", which is already used in cases where "New" should really have been "Add" e.g. -ItemProperty; all the other end-of-life verbs make far worse complements

   * Pair with New

If we weren't starting from this broken state of an officially blessed non-verb verb, then Create/Destroy would have been the obvious pair.

I find the Transform verb useful for data.  It is useful for when you are making some changes in data but retaining the same format/schema. The verb Convert doesn't make sense because there is not a schema change.

Proposed deny verb in template format:

Verb name = Deny

Description = Deny setting is used to override inherited and direct permissions. To remove a Deny permission use Revoke. Revoke applies to both Grants and Denies.

Category = Security

Domains = SQL Server, NTFS, SharePoint, IIS, AD

Alt verbs = Set, Update, Block

Pair with Revoke

I use powershell to monitor traffic on two CAN bus networks - for electric wheel chairs...

Sometimes I want to "Bridge" the two networks together - so that traffic from either is transmitted to the other.

I also hear this term used in Joomla - for "Bridging" one Web based photo album app to another - making sure the content of the two are kept in sync.

I think of it as Actively bridging two things together in a continous fashion.

Maybe it's just me... I could use new-bridge, or maybe start-bridge.

Then again maybe it makes sense to:

$t1 = new-database

$t2 = new-database

$b = bridge-database $t1 $t2 -SyncDeletions

$b.start();

$b.stop();

The verb I use all the time is "Check". While in v1 check-* cmdlets were renamed to test-*, these two verbs have an important differenct.

Test implies an action like a synthetic transaction where you provide some input and verify the output. Check, on the other hand, is more passive where you are just peeking in to see how something is doing.

Moving out of the technology arena allows me to provide a great example. If I want to know whether my baby is sleeping or not, I don't "test" the baby, rather I "check" the baby.

The same really applies to things like configuration or services. If I want to know whether or not a service is running, test doesn't fit, but check does (regardless of what the Test-ServiceHealth cmdlet in Exchange is called.) The same goes for verifying that something is configured properly, I really want to just check the current state - not test it.

Verb name: Check

Description: To determine if an entity is in a particular state

Category: Diagnostic

List of at least 5 significantly different applicable domains: Services, file, account, mailbox, queue, configuration, DNS

List of at least 3 alternative verbs from the approved list: Test, Ping, Measure

Pair with: NA

-Chris

If you haven't seen the post on PowerShell standard verbs from the PowerShell team it is worth reading

Verb name: Script

Category: Common

Applicable Domains: Windows shares, Active Directory, Databases, IIS, Exchange, Virtual Server

Alternative Verbs: Get, Backup, Export

Pair with: Not Applicable

Description:  Used to generate a script to recreate an object that is easy to modify or reuse elsewhere.  The script created could be domain specific (i.e. TSQL) or a PowerShell script.  This is very useful when you have objects that have properties configured by multiple commands.  This is true even if you can get the object from PowerShell and it shows the additional properties.  Just because you might be able to see all the properties, it doesn't mean it includes an easy way to generate a similar object.

Here are 3 examples:

--------------

First, a Windows share, in order to recreate it you need a number of properties that were probably created seperately.  You have the actual share properties (ShareName, FileSystem Path, caching...), the share permissions (who has access to the share), and finally the NTFS permissions (who has access to the underlying file system).  Even if you have one command that had parameters for all of those, you would still want to be able to generate a script to recreate an existing share.  

Script-Share -Name "Installs" -ComputerName MyServer -IncludeNTFSPermissions -IncludeSharePermissions

Alternatives for Windows Share:

Get-ShareScript -Name "Installs" -ComputerName MyServer -IncludeNTFSPermissions -IncludeSharePermissions

Backup-Share -Name "Installs" -ComputerName MyServer -IncludeNTFSPermissions -IncludeSharePermissions -ScriptOnly

Export-Share -Name "Installs" -ComputerName MyServer -IncludeNTFSPermissions -IncludeSharePermissions -AsScript

--------------

Second, a SQL Server database.  You might want to generate a script that includes the definition of tables, views, stored procedures, database creation, users logins...  Doing so by seeing the current properties is very dificult to say the least.

Script-SQLDatabase -ServerInstance DBSERVER1 -Database Commerce -IncludeObjects 'Tables','Views','Stored Procedures','Permissions' -IncludeUseDatabase

Alternatives for SQL:

Get-SQLDatabaseScript -ServerInstance DBSERVER1 -Database Commerce -IncludeObjects 'Tables','Views','Stored Procedures','Permissions' -IncludeUseDatabase

Backup-SQLDatabase -ServerInstance DBSERVER1 -Database Commerce -IncludeObjects 'Tables','Views','Stored Procedures','Permissions' -IncludeUseDatabase -ScriptOnly

Export-SQLDatabase -ServerInstance DBSERVER1 -Database Commerce -IncludeObjects 'Tables','Views','Stored Procedures','Permissions' -IncludeUseDatabase -ScriptSchemaOnly

--------------

And finally, a Windows Service.  There are already 8 cmdlets to work with services including New-Service and Get-Service.  If you want a PowerShell script to recreate an existing service none of the existing ones can do it.  You would want it to give you a New-Service cmdlet with the correct parameters in order to recreate the service.

Script-Service -Name MyService

Alternatives for Service:

Get-ServiceScript -Name MyService

Backup-Service -Name MyService -ScriptOnly

Export-Service -Name MyService -AsScript

--------------

The downside to using alternative verbs is that you need to use additional references in either the Noun or in parameters to make it clear that it will return a script.  If you have a cmdlet that only returns a script, it almost requires you to change the Noun in order for it to be understandable.  But, if you do that it will no longer be able to get all commands related to that Noun as easily.

Thanks for all the greate work you've done with PowerShell so far.

How about Upgrade as this is a common lifecycle concept for administrators and the other terms (namely update and install) have different connotations that will potentially cause confusion.

Proposed upgrade verb in template format:

Verb name = Upgrade

Description = Upgrade is used to perform major version or minor patch level changes to a product, operating system, data, or files. Upgrade may not be reversible (See downgrade) depending on the inherit upgrade abilities and structure of the item being upgraded.

Category = Lifecycle

Domains = SQL Server, SharePoint, other server applications or even file types.

Alt verbs = Set, Update, Install

Reciprocal verb would be Downgrade