vscode-powershell icon indicating copy to clipboard operation
vscode-powershell copied to clipboard

Cannot get path of running script in $MyInvocation.InvocationName

Open kakogawa opened this issue 3 years ago • 19 comments

Prerequisites

  • [X] I have written a descriptive issue title.
  • [X] I have searched all issues to ensure it has not already been reported.
  • [X] I have read the troubleshooting guide.
  • [x] I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
  • [X] I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
  • [ ] If this is a security issue, I have read the security issue reporting guidance.

Summary

In versions 2022.5.0 and 2022.5.1 To get the path of a running script. i tried $MyInvocation.InvocationName but I could not get the path by this command.

Similarly, to retrieve the path of a script running on $PSScriptRoot This also did not retrieve the path.

I downgraded the version to 2021.12.0 and got the path correctly

Thank you

Translated with www.DeepL.com/Translator

PowerShell Version

Name                           Value
----                           -----
PSVersion                      7.2.3
PSEdition                      Core
GitCommitId                    7.2.3
OS                             Microsoft Windows 10.0.19044
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visual Studio Code Version

1.67.0
57fd6d0195bb9b9d1b49f6da5db789060795de47
x64

Extension Version

don't work
2022.5.0 and 2022.5.1

work
[email protected]

Steps to Reproduce

$MyInvocation.InvocationName

Visuals

No response

Logs

No response

kakogawa avatar May 08 '22 23:05 kakogawa

Thanks @vadhbka were you debugging when you hit this?

SydneyhSmith avatar May 09 '22 18:05 SydneyhSmith

I have always used $MyInvocation.InvocationName to create the temp folder. recently the temp folder was something wrong So I noticed it.

kakogawa avatar May 09 '22 18:05 kakogawa

@vadhbka this variable is dynamically populated depending on the context, you can't just run it at the command line, if it's present in a script it will present what you want, and if you are stopped in the debugger it will do that too. This is a PowerShell thing, has nothing to do with the extension, unless I'm missing something. I don't see any issue here, this behavior is the same in the previous versions. Can you provide a specific reproduction?

image

JustinGrote avatar May 09 '22 18:05 JustinGrote

This is what happens when debuging a script. It is not at command line. Since the behavior is changed by changing the version of the extension, I think it is a bug in the extension.

The image has been corrected and re-uploaded. bbb

kakogawa avatar May 09 '22 19:05 kakogawa

Hi I am facing the same problem. I have a script that uses "$MyInvocation.InvocationName" to retrieve the path of my script and since I updated to the latest version, this script returns "." instead of the full path.

CarlosAndreuLlaneras avatar May 11 '22 09:05 CarlosAndreuLlaneras

@CarlosAndreuLlaneras I relieve to know that this was not just my problem. thank you!

kakogawa avatar May 11 '22 10:05 kakogawa

@vadhbka In the meanwhile I am using "$ScriptPath = Split-Path -Parent $PSCommandPath" instead of "$ScriptPath = Split-Path $MyInvocation.InvocationName". It works for me. Regards

CarlosAndreuLlaneras avatar May 11 '22 10:05 CarlosAndreuLlaneras

@vadhbka thanks for the update! I agree with @CarlosAndreuLlaneras because this makes your script immune to differences in how it is invoked (dotsource vs direct run). This happens in PowerShell itself, not just vscode, we just changed how it gets invoked but this exposes a flaw in your script, not necessarily in vscode.

Test.ps1

$myinvocation.InvocationName

image

@andschwa this looks like a "regression" (more like behavior change) from changing how the debug invokes scripts (since now it dotsources rather than running directly), but I don't know if there's anything we can do other than call it out as a "breaking" change.

JustinGrote avatar May 11 '22 15:05 JustinGrote

Hm, that's odd. I thought we were always dot-sourcing scripts. In fact, there was a regression where we changed to using the ampersand call-operator and had to change it back to dot-sourcing: https://github.com/PowerShell/PowerShellEditorServices/pull/1652

andyleejordan avatar May 11 '22 16:05 andyleejordan

@JustinGrote Now I understand why this problem occurred. Thank you!

@CarlosAndreuLlaneras

In the meanwhile I am using "$ScriptPath = Split-Path -Parent $PSCommandPath" instead of "$ScriptPath = Split-Path $MyInvocation.InvocationName". It works for me.

This is a good method. I will replace $PSCommandPath too. Thanks for letting me know!

kakogawa avatar May 11 '22 20:05 kakogawa

Hm, that's odd. I thought we were always dot-sourcing scripts. In fact, there was a regression where we changed to using the ampersand call-operator and had to change it back to dot-sourcing: PowerShell/PowerShellEditorServices#1652

We were always dot sourcing, but when this worked previously it was done via AddScript(string, bool) where the bool controls if it's dot sourced. Using an invocation operator like . or & changes the invocation name. Honestly I'd consider it a PowerShell bug, one we should for sure fix either way.

It's like it just looks at the first token rather than the first pipeline element.

That said, I also agree that this is not the right use case for InvocationName. I do not have any strong preferences for how we handle it on the extension side.

SeeminglyScience avatar May 11 '22 20:05 SeeminglyScience

Think we should use AddScript explicitly here? Might make things "just work" a bit better for users.

andyleejordan avatar May 11 '22 21:05 andyleejordan

Sorry I meant AddCommand. But yeah ideally. That said, we were using it and switched a little bit before I joined I think. So I imagine there was a reason, though I don't know what it was.

SeeminglyScience avatar May 11 '22 21:05 SeeminglyScience

I'll check the Git history and find out why.

andyleejordan avatar May 12 '22 19:05 andyleejordan

The change to dot-source when you hit F5 was a breaking change for my workflow.

I routinely have module function implementations in .PS1 files and I dot-source them from .PSM1 files. While I'm developing the functions, I would open the .PS1 file in VS Code and then use F5 and the InvocationName to exercise the new functions under the debugger:

$isDotSourced = $MyInvocation.InvocationName -eq '.'
if (-not $isDotSourced)
{
  // Execute some functions to test them
}

I don't want the test code to execute when I import the module that dot-sources the .PS1 file.

NeilBrenMS avatar May 12 '22 21:05 NeilBrenMS

@NeilBrenMS the extension has always dot-sourced, with the exception of maybe a month during a preview window.

andyleejordan avatar May 12 '22 23:05 andyleejordan

I routinely have module function implementations in .PS1 files and I dot-source them from .PSM1 files. While I'm developing the functions, I would open the .PS1 file in VS Code and then use F5 and the InvocationName to exercise the new functions under the debugger:

You may want to set a variable in your psm1 instead. InvocationName reading as . instead of the actual invocation name is a bug that may be fixed some day.

SeeminglyScience avatar May 13 '22 14:05 SeeminglyScience

When debugging a script $MyInvocation, $PSScriptRoot and $PSCommandPath are all empty. VSCode 1.74 and PowerShell extension 2022.11.

tschy2m avatar Dec 09 '22 14:12 tschy2m

Currently, I have confirmed that $MyInvocation.InvocationName does not work but $PSScriptRoot and $PSCommandPath do

Visual Studio Code Version:1.76.0 PowerShell:7.3.3 Extension Version:2023.2.1

kakogawa avatar Mar 01 '23 22:03 kakogawa