Description

Michael Klement (mklement0)

opened on Nov 12, 2019

Issue body actions

Summary of the new feature/enhancement

Symlinks (symbolic links) are a staple of the Unix world and are becoming increasingly common on Windows too.

For scripts invoked via symlinks, the "reflective" variables that contain the running script's location (directory, $PSScriptRoot) and $PSCommandPath currently reflect only the link's information, not (also) the underlying file's information.

(Reporting the link's information is consistent with the behavior of POSIX-like shells such as Bash, via $0 and $BASH_SOURCE).

While you can manually investigate the paths contained in these variables to find the true script location and file name, it would be nice to have this information automatically available.

As an aside: Even manual investigation is currently nontrivial - see #10640

Proposed technical implementation details (optional)

One option that doesn't require introducing new automatic variables (which is always problematic) is to add a NoteProperty member name, say, .Target to the $PSScriptRoot and $PSCommandPath variables that reflects the underlying script file's true directory and full filename, respectively.

That way, you could use $PSCommandPath.Target to get the running script's true full path, for instance.

While somewhat obscure, this follows the pattern of the NoteProperty members the $PROFILE automatic variable is decorated with, which reflect the paths of the various profile types and scopes.

Documenting these non-obvious properties clearly should be sufficient, however.

Activity

1. Michael Klement (mklement0)

   added

   Issue-Enhancementthe issue is more of a feature request than a bugthe issue is more of a feature request than a bug

   on Nov 12, 2019
2. iSazonov commented on Nov 14, 2019

   

   Ilya (iSazonov)

   on Nov 14, 2019

   Collaborator

   More actions

   Can Resolve-Path help in the scenario?

   It seems there is no single place where we set value to an automatic variable. So it is not easy to add a property.

   Also we could change type of the variable from string to FileInfo but it looks as a breaking change.
3. Ilya (iSazonov)

   added

   WG-Enginecore PowerShell engine, interpreter, and runtimecore PowerShell engine, interpreter, and runtime

   on Nov 14, 2019
4. mklement0 commented on Nov 14, 2019

   

   Michael Klement (mklement0)

   on Nov 14, 2019

   ContributorAuthor

   More actions

   Can Resolve-Path help in the scenario?

   No, but the yet-to-be-implemented Convert-Path -Canonical would help - see #10640

   It seems there is no single place where we set value to an automatic variable.

   I haven't looked, but are you saying that these specific automatic variables are filled in different places based on whether the code unit is a script or a module?

   Also we could change type of the variable from string to FileInfo but it looks as a breaking change.

   While that would be nice, I fear it is too problematic a change.
5. mklement0 commented on Nov 14, 2019

   

   Michael Klement (mklement0)

   on Nov 14, 2019

   ContributorAuthor

   More actions

   Actually, the more I think about this: I think just using Convert-Path -Canonical on demand should be enough for this use case, so I'll close this issue.
6. Michael Klement (mklement0)

   closed this as completedon Nov 14, 2019
7. iSazonov commented on Nov 14, 2019

   

   Ilya (iSazonov)

   on Nov 14, 2019

   Collaborator

   More actions

   are you saying that these specific automatic variables are filled in different places based on whether the code unit is a script or a module?

   I mean that we haven't methods like SetPSCommandPathVariable() and SetPSScriptRootVariable(). (It is true for all automatic variables). We use one universal method SetAutomaticVariable().

   Really we set these variables in 2 places - for module and for script block.

   Reacted by Michael Klement
8. Ilya (iSazonov)

   added

   Resolution-AnsweredThe question is answered.The question is answered.

   on Nov 14, 2019

Issue actions