Powershell: Start-Sleep cmdlet is misnamed; should be Invoke-Sleep

Created on 12 Jun 2017  路  8Comments  路  Source: PowerShell/PowerShell

https://technet.microsoft.com/en-us/library/ms714428(v=vs.85).aspx states (emphasis added):

The Invoke verb is used to perform an operation that is generally a synchronous operation, such as running a command. The Start verb is used to begin an operation that is generally an asynchronous operation, such as starting a process.

Therefore, Start-Sleep, which is _synchronous_, should be called Invoke-Sleep.

It's probably too late to change this, but:

  • perhaps an Invoke-Sleep _alias_ could be defined.

  • either way, the inconsistency should be _documented_.

Area-Cmdlets-Utility Issue-Discussion Resolution-Answered

Most helpful comment

My sincere apologies, @kilasuit: Being abrasive and rude was truly not my intent; I was hoping to inject some levity, but clearly failed - and I can now see why.

I see both sides of the debate, and @SeeminglyScience has a point about potentially breaking things.

As for the semantics:

Start-Sleep is _invariably_ synchronous.

For cmdlets that optionally allow changing the "synchronicity" of the behavior, such as Start-Process and Invoke-Command, the sensible approach is to name them for their _default_ behavior - which the latter two cmdlets got right.

This would be a change for the sake of change

No, it would be a change that makes the PowerShell ecosystem more consistent - _in the long run_, for _future_ learners of PowerShell.

I don't know how many people never noticed / will never notice the inconsistency, but I assure you there are ones that do and will.

That said, perhaps it sufficient to follow @SeeminglyScience's advice:

I'm all for the inconsistency being documented.

So, to bring this to a close:

All 8 comments

I genuinely see no benefit of making this change other than semantics

That may be, but internal semantic consistency is valuable in and of itself, in my opinion. If the PS team isn't naming things according to their own rules, it becomes more acceptable to mis-name things in wider use. Lead by example, and all that.

I'd be in favor of adding an alias for it, at least, if not switching out the cmdlet name and providing an alias under the old name. 馃し鈥嶁檪

I agree with @kilasuit. That horse has left the barn and introducing an alias would only serve to confuse folks IMO.

When it comes to language design, you have to walk a line between complete status quo and "gilding the lily". This feels more like the latter.

I like Ander's approach with C# where every new features starts out with a score of -100 and has to demonstrate enough value to at least get past break-even before it is even seriously considered.

I don't disagree @rkeithhill but I do think there's a bit of a "cost difference" as it were between "a feature" and "the name of a feature". 馃檪

(This comment originally contained a misguided attempt at satire by me. Since it contributed nothing to the discussion, I've redacted it.)

I'm all for the inconsistency being documented.

That said, changing the name of the cmdlet has a minor potential to break, even if a compatibility alias added. Anything specifically looking for a cmdlet named Start-Sleep (like a proxy command) would no longer work. Adding an alias Invoke-Sleep has a pretty high possibility of hijacking any custom Invoke-Sleep functions. Generally speaking the risks are pretty low, but I don't think they outweigh the gain.

@mklement0 I don't know why you felt the need to be so abrasive and rude but here's the extended reason why this change makes no sense to me, not that I felt to those like yourself that has knowledge of the codebase needed it extended to the full reason.

Start-Process a command that quite rightly pointed out the verb Start is generally used for an asynchronous command, has the -Wait parameter which changes the dynamic to a synchronous command.
Invoke-Command a command that quite rightly pointed out the verb Invoke is generally used for a synchronous command, has the -AsJob parameter which changes the dynamic to be an asynchronous command.

Now if both Invoke & Sleep verbs missed out the generally & both these commands didn't have Parameters that change their synchronous nature then you would be 100% correct in that it would be semantically correct to be Invoke-Sleep and not Start-Sleep, however as both verbs allow flexibility in both options of synchronicity I feel that your ask is of such little value that it's not worth the change. Also you have to consider that you would never say that as a person I am going to go an invoke sleep when you go to bed, it would be that you go and try to start to sleep.

This would be a change for the sake of change with actually almost no benefit bar being entirely pedantic in nature and actually would lead to confusion. Which is why I made my original comment, one I still stand by considering I've been not just a user but also a trainer of PowerShell and every user who I've come across who looks at the cmdlet just by name understands what it does and those that may be unsure can always read the help for Start-Sleep & they would understand what Start-Sleep does by the Description from the help that states

The Start-Sleep cmdlet suspends the activity in a script or session for the specified period of time. You can use it for many tasks, such as waiting for an operation to complete or pausing before repeating an operation

So yeah, to wrap up I can't see any real benefit from making this change

My sincere apologies, @kilasuit: Being abrasive and rude was truly not my intent; I was hoping to inject some levity, but clearly failed - and I can now see why.

I see both sides of the debate, and @SeeminglyScience has a point about potentially breaking things.

As for the semantics:

Start-Sleep is _invariably_ synchronous.

For cmdlets that optionally allow changing the "synchronicity" of the behavior, such as Start-Process and Invoke-Command, the sensible approach is to name them for their _default_ behavior - which the latter two cmdlets got right.

This would be a change for the sake of change

No, it would be a change that makes the PowerShell ecosystem more consistent - _in the long run_, for _future_ learners of PowerShell.

I don't know how many people never noticed / will never notice the inconsistency, but I assure you there are ones that do and will.

That said, perhaps it sufficient to follow @SeeminglyScience's advice:

I'm all for the inconsistency being documented.

So, to bring this to a close:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

abock picture abock  路  3Comments

aragula12 picture aragula12  路  3Comments

garegin16 picture garegin16  路  3Comments

JohnLBevan picture JohnLBevan  路  3Comments

manofspirit picture manofspirit  路  3Comments