Repository navigation
Runspace names listed by Get-Runspace should have meaningful names when possible #2426
Description
Activity
I agree that the word "runspace" is not needed. Yes, we can include the target computer name in the runspace name but the computer name is already included in the list returned by Get-Runspace so it would be redundant. So maybe we should just stick with the name reflecting the type of runspace:
Get-Runspace
Id Name ComputerName Type State Availability
1 DefaultHost localhost Local Opened Busy
2 SSH-2 paulhig-3 Remote Opened Available
3 SSH-3 paulhig-vmubuntu Remote Opened Available
4 WinRM-4 localhost Remote Opened AvailableAlso I noticed that the Type field from Get-Runspace is not correct for SSH remote runspaces (it indicates "Local" when it is a "Remote" type), so that should also be fixed as part of this effort.
I see that mark down did not display the Get-Runspace list correctly. Trying again here.
PS C:\> Get-Runspace Id Name ComputerName Type State Availability -- ---- ------------ ---- ----- ------------ 1 DefaultHost localhost Local Opened Busy 2 SSH-2 paulhig-3 Local Opened Available 3 SSH-3 paulhig-vmubuntu Local Opened Available 4 WinRM-4 localhost Remote Opened Available
This would make it easier for users to determine which runspace in the list is the one they want to examine or debug.
Yes, we can include the target computer name in the runspace name but the computer name is already included in the list returned by Get-Runspace so it would be redundant.
From these two statements, I think it would be good to add
Protocolto the output:PS C:> Get-Runspace
Id Name Protocol ComputerName Type State Availability 1 Runspace1 IPC localhost Local Opened Busy 2 Runspace2 SSH paulhig-3 Local Opened Available 3 Runspace3 SSH paulhig-vmubuntu Local Opened Available 4 Runspace4 WinRM localhost Remote Opened Available It is possible to have more than one connection to a particular server so mabye it should be:
Winrm-#This begs the question: what is the difference between Runspace# and WinRM#:
Id Name id Name 1 Runspace1 1 WinRM1 2 Runspace2 2 WinRM2 3 Runspace3 3 WinRM3 4 Runspace4 4 WinRM4 - added this to the milestone
on Nov 4, 2016 - modified the milestones: ,
on May 25, 2017 Steve Lee (@SteveL-MSFT) Maybe PowerShell-Committee make final conclusion about runspace name formats?
- modified the milestones: ,
on Jun 14, 2017 @PowerShell/powershell-committee agreed that it doesn't make sense to store data into the name, instead it makes sense to expose a Protocol property (along with others) if they are useful
Paul Higinbotham (@PaulHigin) Could you please place the powershell-committee conclusion in your first post?
This has nothing to do with protocol, but instead is about what runspaces are used for when listed via Get-Runspace. PowerShell internally has many uses for non-default runspaces and it would be good to indicate that when debugging sessions with multiple runspaces. Note that the original request for this came from a committee member (Jeffrey). We already provide a runspace name that can be attached to a created runspace. This is about providing meaningful names for PowerShell internally created runspaces.
is about what runspaces are used for
Agreed. For me it is 100% about knowing which runspace my code is running in so I can debug it. This is for the attach to PSHost process case. Usually it is id 1 but that determination always feels like a guess. :-)
The feedback was improving
Get-Runspaceoutput is great - but it looked like adding a property might be a better way to do that so folks don't start parsing theNameproperty.As long as that property is displayed when I type
Get-Runspace- that works for me. :-)Adding another property feels like overkill to me. I don't expect people to be parsing the Name property. It is just a visual indicator to aid debugging.
It seems we should look Get-PSSession too.
- added a commit that references this issue
on Feb 4, 2018 - added a commit that references this issue
on Apr 24, 2018 - added a commit that references this issue
on Aug 6, 2026
Currently when a new runspace is created its default name is "Runspace#". The only exception to this is the runspace created on a host process for IPC and it is named "RemoteHost".
We should provide runspace names with meaning when possible. This would make it easier for users to determine which runspace in the list is the one they want to examine or debug.
For example: