Skip to content

variable completion of $: provides no results #10239

Closed

Description

@msftrncs

Steps to reproduce

$:<CTRL SPACE>

# OR

tabexpansion2 '$:' 2 # result set shows that it found nothing to match

Expected behavior

Expected was a full list of all the variables that could be used at least with the notation $:

Actual behavior

No results are returned, or list is offered.

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0-preview2.27045
PSEdition                      Core
GitCommitId                    7.0.0-preview2.27045
OS                             Microsoft Windows 10.0.18941
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Previous versions behave the same way.

I believe this should work, since $: is a valid start to specifying a variable. See 033ef6c for a commit that would fix this issue.

It might need to be determined if the : representing a blank drive/scope/provider field should be stripped from the returned completions, when they are not needed), and if the common scopes and providers should still be included in the list.

Activity

  1. added
    Issue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get a
    on Jul 27, 2019
  2. iSazonov commented on Jul 29, 2019

    @iSazonov
    Collaborator

    : is a drive separator and perhaps we need to limit using the char in variable names otherwise it can too complicate our code.

  3. msftrncs commented on Jul 29, 2019

    @msftrncs
    ContributorAuthor

    Additionally, ${: also provides no results. At that point, the : is a valid character, and also still a scope / drive / provider separator, and at least at present, a empty scope is allowed in the $ and @ syntaxes.

    Just to clarify, $:<anything><CTRL SPACE> and ${:` fail to bring up completions, and both are fixed by 033ef6c.

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

    @microsoft-github-policy-service
    Contributor

    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.

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

    @microsoft-github-policy-service
    Contributor

    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.

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

    @microsoft-github-policy-service
    Contributor

    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.

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

    @microsoft-github-policy-service
    Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    In-PRIndicates that a PR is out for the issueIssue-Questionideally support can be provided via other mechanisms, but sometimes folks do open an issue to get aResolution-No ActivityIssue has had no activity for 6 months or moreWG-Interactive-IntelliSensetab completion

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions