Repository navigation
Runspace names listed by Get-Runspace should have meaningful names when possible #2426
Description
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:
- The first runspace created in a session with a PSHost should be named "HostRunspace" (now it is "Runspace1").
- The IPC host runspace should be renamed to "IPCHostRS".
- The runspace proxy created for a WinRM remote session should be "WinRMRunspace#".
- The runspace proxy created for an SSH remote session should be "SSHRunspace#".
- Internal runspaces created by the PowerShell engine could be something like "InternalRS#", or "PSTempRS#".
- Workflow runspaces could be "PSWorkflowRS#".
Activity
jpsnover commentedon Oct 5, 2016
Is it possible to include the name of the remote host in #3 and #4
e.g.
Winrm-ADServer
SSH-FSServer
I think this would be more valuable then having the word "runspace".
It is possible to have more than one connection to a particular server so mabye it should be:
Winrm-#
PaulHigin commentedon Oct 5, 2016
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 Available
PaulHigin commentedon Oct 5, 2016
Also 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.
PaulHigin commentedon Oct 5, 2016
I see that mark down did not display the Get-Runspace list correctly. Trying again here.
iSazonov commentedon Nov 1, 2016
From these two statements, I think it would be good to add
Protocolto the output:PS C:> Get-Runspace
This begs the question: what is the difference between Runspace# and WinRM#:
iSazonov commentedon Jun 3, 2017
Steve Lee (@SteveL-MSFT) Maybe PowerShell-Committee make final conclusion about runspace name formats?
SteveL-MSFT commentedon 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
iSazonov commentedon Jun 15, 2017
Paul Higinbotham (@PaulHigin) Could you please place the powershell-committee conclusion in your first post?
PaulHigin commentedon Jun 15, 2017
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.
rkeithhill commentedon Jun 15, 2017
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. :-)
lzybkr commentedon Jun 15, 2017
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.rkeithhill commentedon Jun 15, 2017
As long as that property is displayed when I type
Get-Runspace- that works for me. :-)PaulHigin commentedon Jun 15, 2017
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.
iSazonov commentedon Jun 15, 2017
It seems we should look Get-PSSession too.
Enable setting PSSession Name when using SSHTransport and added Trans…
Keep uptodate (#1)
Enable setting PSSession Name when using SSHTransport and added Trans…