Fix indexer for System.Management.Automation.PathInfoStack type

Get-Location -Stack currently outputs a [System.Management.Automation.PathInfoStack] stack object rather than an array of [System.Management.Automation.PathInfo] instances representing the individual locations in the stack.

While this is behavior is documented, and changing it would technically be a breaking change, it should be considered for two reasons:

Outputting a custom stack object rather than an array of locations is of little benefit, given that location stacks are meant to be managed via the *-Location cmdlets.
- Stack management support in these cmdlets currently lacks options for deleting / clearing a stack, but that is a separate issue - see Managing location stacks via the *-Location cmdlets lacks ability to clear stacks #4643.
- As an aside: While calling the .Clear() method on the stack object may seem like a workaround for the current inability to clear a stack using cmdlets, it doesn't actually work (only clears the object returned, not the actual stack).
Outputting a custom stack object rather than an array of locations contravenes the expectation that a regular PowerShell array is output that can be indexed into, which doesn't work as intended with the stack object (.ToArray()[0] must be used, for instance).
- The current default output certainly looks like a collection (array) of [System.Management.Automation.PathInfo] instances.

Current behavior

# Try to obtain the 2nd location from the bottom of the stack, which is "/"
> Push-Location /; Push-Location $HOME; (Get-Location -Stack)[-2]
# !! No output

Because Get-Location -Stack returns a scalar - the stack object - indexing into the scalar with [-2] makes PowerShell return $null.

To make this work currently, .ToArray() must be used:

# Note the awkward .ToArray()
> Push-Location /; Push-Location $HOME; (Get-Location -Stack).ToArray()[-2]

Path
----
/

Desired behavior

If a regular array is returned, indexing will work as expected.

> Push-Location /; Push-Location $HOME; (Get-Location -Stack)[-2]

Path
----
/

Environment data

PowerShell Core v6.0.0-beta.5 on macOS 10.12.6
PowerShell Core v6.0.0-beta.5 on Ubuntu 16.04.3 LTS
PowerShell Core v6.0.0-beta.5 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.483 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)

To avoid a breaking change, I wonder if adding a -StackAsArray (or variant) may be viable?

I haven't done any research, but I'd be surprised if anyone relies on the existing behavior, given that the fact that a special collection object is returned is neither obvious nor useful.

Someone who did run into the inability to index with, say, (Get-Location -Stack)[-1] probably worked around that with (Get-Location -Stack) | Select-Object -Last 1 (note the parentheses), which will continue to work if the proposed change is made.

Workaround (Get-Location -Stack).ToArray()[-1], however, will cease to work, because .ToArray() is invariably applied to each element of an array.

A quick search on GitHub says some people will be broken as they are using .ToArray() but the majority of uses is simply to get the count and that should continue to work.

Can we add ToArray() in PathInfo[] by ETS?

Ilya (@iSazonov)

Ilya (@iSazonov):

Great idea; we could do the C# equivalent of the following:

# Sample location-stack array.
# I suggest using a regular [object[]] array, as usual.
$a = 'one', 'two'

# Insert helper type name.
$a.pstypenames.insert(0, 'LocationStack')

# Add a .ToArray() method to the helper type, unless already defined.
if (-not $a.psobject.methods['ToArray']) {
  Update-TypeData -TypeName LocationStack -MemberType ScriptMethod -MemberName ToArray -Value { $this  }
}

We could use the same technique for adding a .Name property, which the current stack objects have.

PowerShellTeam

I would like to do this, and maybe a couple of other things related to location stacks (as separate issues). Mind if I go at it? This will be my first contrib for this repo, but I'm reading the guideline and I think I can do this. I'm asking PowerShellTeam (@powershell/powershell) for an assignment.

Alan McBee (@AlanMcBee)

Alan McBee (@AlanMcBee) Welcome to pull the fix!
Github doesn't allow to explicitly assign you but the issue is now yours.

It seems that the problem here is that the indexer for System.Management.Automation.PathInfoStack is broken and if that was fixed then this issue would be resolved. This is likely a bucket 3 breaking change.

PS> $s = (get-location -stack)
PS> $s

Path
----
/
/Users/steve/test
/Users/steve

Expected this test to pass:

$s[1] | Should -BeExactly $s.ToArray()[1]
InvalidResult:
Line |
   1 | $s[1] | Should -BeExactly $s.ToArray()[1]
     | Expected exactly /Users/steve/test, but got $null.

Where $s[1] should return the value /Users/steve/test

This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.

This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

Navigation Menu

Repository navigation

Fix indexer for System.Management.Automation.PathInfoStack type #4642

Current behavior

Desired behavior

Environment data

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Fix indexer for System.Management.Automation.PathInfoStack type #4642

Description

Current behavior

Desired behavior

Environment data

Activity

SteveL-MSFT commented on Sep 23, 2017

mklement0 commented on Sep 23, 2017

SteveL-MSFT commented on Sep 23, 2017

iSazonov commented on Sep 25, 2017

mklement0 commented on Sep 25, 2017

AlanMcBee commented on Nov 26, 2019

iSazonov commented on Nov 26, 2019

SteveL-MSFT commented on Jun 8, 2021

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 16, 2023

microsoft-github-policy-service commented on Nov 23, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions