Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$PSScriptRoot is not populated when used in a default value for a non-mandatory script parameter #4688

Closed
ghost opened this issue Aug 27, 2017 · 8 comments

Comments

@ghost
Copy link

@ghost ghost commented Aug 27, 2017

Steps to reproduce

Run this script (via PowerShell -File ....)

param(
    [Parameter(Mandatory = $false)]
    [string] $Foo = 'hi\{0}\hi' -f $PSScriptRoot
)

Write-Host $Foo

Function Bar {
    param(
        [Parameter(Mandatory = $false)]
        [string] $Bar = $PSScriptRoot
    )
    Write-Host $Bar
}

Function Baz {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory = $false)]
        [string] $Baz = $PSScriptRoot
    )
    Write-Host $Baz
}

Bar
Baz

Expected behavior

hi\C:\tmp\hi
C:\tmp
C:\tmp

Actual behavior

hi\\hi
C:\tmp
C:\tmp

Environment data

Name                           Value
----                           -----
PSVersion                      5.1.16353.1000
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.16353.1000
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[edited by @daxian-dbw to put the repro in code blocks]

@mklement0

This comment has been minimized.

Copy link
Contributor

@mklement0 mklement0 commented Aug 28, 2017

Actually, what matters is whether the script is an advanced (cmdlet-like) script or not.
By using a [Parameter(...)] attribute, you're implicitly making your script an advanced script, even without decorating your param(...) block with an explicit [CmdletBinding()] attribute.

Combining an advanced script with invocation via powershell -File is what produces the symptom, as the following simplified script demonstrates:

Save the following as t.ps1 in the current dir:

[CmdletBinding()]
param(
  $Foo = $PSScriptRoot
)

"[$Foo]"
# Direct invocation works fine.
> ./t.ps1
[/Users/jdoe]

# Invocation via the external CLI with -File shows the symptom:
> powershell -File ./t.ps1
[]

Were you to omit [CmdletBinding()], the symptom would not surface.


Two asides:

  • Your version table shows a Windows PowerShell version. In this case, the symptom also surfaces in PowerShell Core. Generally, you should only report issues here that (also) surface in PS Core, using the latest released version. If a symptom surfaces only in Windows PS, report it on uservoice.com.

  • Please use the fenced code and output blocks provided in the issue template (```powershell ... and ```none ...) - it makes for much more readable representations.

@daxian-dbw

This comment has been minimized.

Copy link
Member

@daxian-dbw daxian-dbw commented Aug 30, 2017

Thanks @mklement0 for the analysis and simple repro! It's really helpful.
It also repros when you dot source a script cmdlet in powershell, for example:

# use the same 't.ps1'
> . .\t.ps1
[]

This is because the automatic variables are not set up before parameter binding for a script cmdlet when they are not going to run in new local scopes. I'm preparing a fix.

@LaurentDardenne

This comment has been minimized.

Copy link

@LaurentDardenne LaurentDardenne commented Feb 16, 2018

@SteveL-MSFT
This fix does not have the 'Breaking-Change' label ? Is it correct ?

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

@SteveL-MSFT SteveL-MSFT commented Feb 21, 2018

@LaurentDardenne agree this is technically a breaking change

@iSazonov

This comment has been minimized.

Copy link
Collaborator

@iSazonov iSazonov commented Feb 21, 2018

:-) Any bug fix is a breaking change. I guess this label is useless here.

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

@SteveL-MSFT SteveL-MSFT commented Feb 21, 2018

@iSazonov valid point, I've been thinking about having different degrees of Breaking Change labels as they are not all equal

@iSazonov

This comment has been minimized.

Copy link
Collaborator

@iSazonov iSazonov commented Feb 22, 2018

It make sense only if we want strongly document breaking change buckets in docs and changelog.

@SteveL-MSFT

This comment has been minimized.

Copy link
Member

@SteveL-MSFT SteveL-MSFT commented Feb 22, 2018

I believe we've been trying to use Breaking-Change label on issues/PRs that we believe will have a high chance of impact or that the impact is high if encountered. Agree that technically any bug fix is a breaking change. So as to not dilute this label, I'm removing it from this issue as it's unlikely anyone is expecting the previous behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants
You can’t perform that action at this time.