none
Reliable way to get current script name

    Question

  • I know this has been asked a number of times in various places by various people already.  I apologize as I'm going to ask it again here, as I have yet to find a reliable and re-usable way to accomplish this.

    I'm looking for "best practice" way to return the name of the currently running script in a repeatable and re-usable fashion.  This gets used in various scripts here, and it seems we always come up with slightly different ways of acomplishing it in each script.  I'd like to standardize the approach, which would lead to creating a function or module to complete the task in my mind.

    Unfortunately I've noticed different results when calling the script/function/module from ISE compared to the CLI.  (for one example see - https://connect.microsoft.com/PowerShell/feedback/details/797787/myinvocation-mycommand-returns-null-when-used-as-a-param-default-with-cmdletbinding-in-ise )

    The following work to some degree, but seem to get different results depending on scope (Local, Script, Global, or by numbered scope) and where they are called from (CLI, ISE):

    $((Split-Path$PSCommandPath-Leaf).Replace('.ps1',''))

    $(($MyInvocation.Mycommand.Name).Replace('.ps1',''))

    So what do people use to acomplish this in their scripting practice?  Am I asking too much, or is there no way to reliably return the name of the PS1 script file that was executed no matter where/how it is executed?

    Wednesday, August 28, 2013 8:07 PM

Answers

  • I thought I should also address the original question in this way:  You are asking how to get the script 'Name'.  Your demo shows how you remove the extension to get some string.

    Technically speaking scripts do not have names.  What you are getting is the first part of the filenaqme without any substring that is ".ps1'.  Scripts can have many extensions. 'ps1 is only one possibility.

    A better method would be this:

    ([io.fileinfo]$MyInvocation.MyCommand.Definition).BaseName

    This will always give you the base name no matter what the extension.

    Since there is no technical standard of meaning for 'script name' then you are on  your own with this for implementation.  I also have never heard of anyone needing or caring about this, so called , script name. In normal usage I can see no need or use for it.

    If you are building modules and CmdLets you can give them more information like help.  With a module manifest you can add all manner of comments and useful information.  This is what I meant by learning PowerShell more completely so you can understand what is built in.


    ¯\_(ツ)_/¯

    • Marked as answer by sgrinker Thursday, August 29, 2013 12:08 AM
    Wednesday, August 28, 2013 10:24 PM
  • For anyone that actually cares at this point and is potentially looking for something similar, I have found $MyInvocation.ScriptName to be more reliable for the purposes here.  This is especially true if you are looking to use a Module at all, since this will return the calling scriptname.  Also Scopes don't seem to cause as much headache with this route either.  It seems to work reliably in different environments, and only returns $Null if called from the CLI or not from within a saved script.

    Granted to be fair, I'm still trying to find a good source for a solid definition of $MyInvocation.ScriptName to be sure it's reliable.

    JRV's recomendation of using ([io.fileinfo]$MyInvocation.MyCommand.Definition).BaseName or just $MyInvocation.MyCommand.Definition does also work, but can get a little rough depending on what is calling the function/module.

    Again, both work... it just depends on what you are after.  Just thought I would share recent findings if anyone is interested.  I'd be curious if anyone has a good reference for more details on $MyInvocation.ScriptName, since as I mentioned documentation appears to be light on what I can find thus far.


    • Marked as answer by sgrinker Wednesday, September 04, 2013 4:56 PM
    • Edited by sgrinker Wednesday, September 04, 2013 5:03 PM
    Wednesday, September 04, 2013 4:56 PM

All replies

  • Here's how I've done it to get the script name and path:

    ($MyInvocation.MyCommand).Definition

    This seems to be pretty reliable.

    The two lines below work to extract the script name itself ($scriptName is the final result):

    $scriptPathArray = ($MyInvocation.MyCommand).Definition.Split("\")
    $scriptName = $scriptPathArray[$scriptPathArray.Length - 1]




    Wednesday, August 28, 2013 8:30 PM
  • The two lines below work to extract the script name itself ($scriptName is the final result):

    $scriptPathArray = ($MyInvocation.MyCommand).Definition.Split("\")
    $scriptName = $scriptPathArray[$scriptPathArray.Length - 1]


    You could also use the Split-Path cmdlet:

    $scriptName = Split-Path -Path $MyInvocation.MyCommand.Definition -Leaf

    Wednesday, August 28, 2013 8:40 PM
  • Here's how I've done it to just get the script name and path:

    ($MyInvocation.MyCommand).Definition
    This seems to be pretty reliable.


    Which is identical to $PScommandPath.

    All of these produce the full file path and have to have the path extracted.

    Split-Path $PSCommandPath

    This will always result in the path of the script calling this.

    Use this to extract the script name

    Split-Path $PSCommandPath -leaf

    That's it.  No more needed.


    ¯\_(ツ)_/¯


    • Edited by jrv Wednesday, August 28, 2013 8:42 PM
    Wednesday, August 28, 2013 8:41 PM
  • I believe $PSCommandPath only exists in PowerShell v3, though.  If you need to support V2, use the $MyInvocation.MyCommand.Definition version instead.

    Wednesday, August 28, 2013 8:43 PM
  • Dave: Nice! I haven't seen the Split-Path cmdlet before but it works perfectly. Thanks!
    Wednesday, August 28, 2013 8:45 PM
  • jrv: No PowerShell 3.0 here. Only 2.0
    Wednesday, August 28, 2013 8:47 PM
  • It works in my PowerShell V2 with no problem. Why?

    Yes - Split-Path is the tool to use.


    ¯\_(ツ)_/¯

    Wednesday, August 28, 2013 8:54 PM
  • $PSCommandPath doesn't exist in V2 when I execute it.

    Wednesday, August 28, 2013 8:55 PM
  • Mystery solved:

    Found this in my profile

    $PSCommandPath=[ref]$MyInvocation.MyCommand.Definition

    It is leftover from  a very old experiment last year.


    ¯\_(ツ)_/¯

    Wednesday, August 28, 2013 9:04 PM
  • Thanks everyone for the quick and great answers!  Yes, I should have mentioned $PSCommandPath was a v3 thing, but I like the use of:

    $PSCommandPath=[ref]$MyInvocation.MyCommand.Definition

    Has anyone else toyed around with creating a Function or Module for this task?  Yes, I realize it can be as simple as one line of code to get the result, but again looking to standardize for multiple people using the same system if possible.  Also, based on various PS versions and scope, I was planning to add a little error handling to get the information no matter what the environement.

    If anyone has created a function, do you just insert it in every script then?  I'd like to get it working in a module, but scopes have proved to be a headache in some scenarios.

    Wednesday, August 28, 2013 9:24 PM
  • Thanks everyone for the quick and great answers!  Yes, I should have mentioned $PSCommandPath was a v3 thing, but I like the use of:

    $PSCommandPath=[ref]$MyInvocation.MyCommand.Definition

    Has anyone else toyed around with creating a Function or Module for this task?  Yes, I realize it can be as simple as one line of code to get the result, but again looking to standardize for multiple people using the same system if possible.  Also, based on various PS versions and scope, I was planning to add a little error handling to get the information no matter what the environement.

    If anyone has created a function, do you just insert it in every script then?  I'd like to get it working in a module, but scopes have proved to be a headache in some scenarios.

     

    That line of code will not work as intended.  It was residue from testing.  i fdon't think it every worked and i forgot to remove it.

    You are asking how to standardize one line of code. Why?  Why make something simple more simple.

    Can you not remember this:

    Split-Path $MyInvocation.MyCommand.Definition -leaf

    How can it be any smaller?


    ¯\_(ツ)_/¯

    Wednesday, August 28, 2013 9:29 PM
  • I can remember it just fine.  It's everyone else that creates code here I'm trying to help out by making something reusable for those that don't know... or don't remember.  We have people at all different levels of PS skillsets, and I was trying to make it easier and get some more standards at the same time.
    • Edited by sgrinker Wednesday, August 28, 2013 9:39 PM
    Wednesday, August 28, 2013 9:34 PM
  • I can remember it just fine.  It's everyone else that creates code here I'm trying to help out by making something reusable for those that don't know... or don't remember.  We have people at all different levels of PS skilsets, and trying to make it easier and get some more standards at the same time.

    What is the likelihood that they will remember the name of a function if they cannot remember a single easy line of script?

    There is not answer to your question. Telepathy is not an option.  Somehow you have to distribute the information or the code.

    Sometimes people have to be required to know something.  If you cannot require that of your people you need to get new people.  It scares me when idiots are given computers and responsibility for information.  It is even scarier when managers think their emplyees are idiots.  Don't know which is worse.

    Post the code in an email to everyone or store it in a file on a file server.  It is up to you to design and set your own standards.  There are not standards for what you ask.


    ¯\_(ツ)_/¯

    Wednesday, August 28, 2013 9:42 PM
  • I understand the point, but cannot agree that creating something like Get-ScriptName wouldn't have any value.  I also don't see the harm in creating some company standards when it comes to creating scripts, I'm not suggesting that the entire world needs to agree on an approach.  One of the great features provided to us with PowerShell is the ability to make our own reusable cmdlets/tools.

    http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/WCL404

    I'm not suggesting that the intent is to create a module just for this specific task alone.  It is a suite of many other much lengthier and more complex tools for tasks that are repeated here often.

    I was surprised to be getting varying results when adding what seemed to be a rather simple cmdlet to the mix, and was looking here to get input from other on how they have acomplished getting the same information.  What I'm running into very likely has to do with the bug menioned above, so I was looking for some better ways to get the same information.

    For the record no one here is indicating that anyone is an "idiot", so I'm not sure why we had to go down that path.

    I wasn't looking for anyone to create a standard for us.  I was interested if anyone has done anything similar and how they went about it.  Apparently you have not done similar, and/or don't see the value in doing so.

    Wednesday, August 28, 2013 9:56 PM
  • I am not saying you can't.  I am saying that we cannot help you. You have to decide what the standards are for your company.  You have to create the modules, the documentation and distribute them.

    We can help with scripts or answer specific questions but you have to make the choices.

    There are no standards assigned to deploying a single line of custom code.

    Libraries are not standards but can implement formats and structures or encapsulate code specific to a corporation.  All of that is up to you.  It is very specific to a company.

    Excuse my idiot reference but I wanted to make it clear that you underestimate the ability of your people to learn.  If you are going to build scripts they had better learn first.  If they can't learn then nothing you do will be of much help. You asked a specific question about how to get the path of the script.  I recommend a new question if you re going to branch off into other areas.

    One you learn PowerShell and realize how it is structured you will see what facilities it has that can be used to create a generalized structure for you modules.  When you get to that point many of these questions will be moot.


    ¯\_(ツ)_/¯

    • Marked as answer by sgrinker Thursday, August 29, 2013 12:08 AM
    • Unmarked as answer by sgrinker Thursday, August 29, 2013 12:08 AM
    Wednesday, August 28, 2013 10:07 PM
  • One other note.

    PowerShell is an enforcement of structure and standards for scripting.  Much of that is built in.  It only requires that you learn it from the ground up.  No cheating by reading the last five pages of the manual to find out who dunnit.


    ¯\_(ツ)_/¯

    Wednesday, August 28, 2013 10:09 PM
  • What I'm running into very likely has to do with the bug menioned above, so I was looking for some better ways to get the same information.

    What 'bug' are you referring to?


    ¯\_(ツ)_/¯

    Wednesday, August 28, 2013 10:12 PM
  • I thought I should also address the original question in this way:  You are asking how to get the script 'Name'.  Your demo shows how you remove the extension to get some string.

    Technically speaking scripts do not have names.  What you are getting is the first part of the filenaqme without any substring that is ".ps1'.  Scripts can have many extensions. 'ps1 is only one possibility.

    A better method would be this:

    ([io.fileinfo]$MyInvocation.MyCommand.Definition).BaseName

    This will always give you the base name no matter what the extension.

    Since there is no technical standard of meaning for 'script name' then you are on  your own with this for implementation.  I also have never heard of anyone needing or caring about this, so called , script name. In normal usage I can see no need or use for it.

    If you are building modules and CmdLets you can give them more information like help.  With a module manifest you can add all manner of comments and useful information.  This is what I meant by learning PowerShell more completely so you can understand what is built in.


    ¯\_(ツ)_/¯

    • Marked as answer by sgrinker Thursday, August 29, 2013 12:08 AM
    Wednesday, August 28, 2013 10:24 PM
  • Sorry to ask such a stupid and unecessary question that is apparently due to my lack of PowerShell experience and understanding.

    A bit over the top in a response?  Possibly.  I just wanted to shed some light on the "extras" in your responses and how they can be interpreted by others, intentional or not.  Little bits like "idiots","never heard anyone caring about this", and "Once you learn PowerShell" don't exactly add anything to the conversation or incite others to join in to the community and ask what they are afraid may be a "dumb" question.  No I'm not actually that bothered by it, but wanted to call attention to it as I find it to be unecessary.  I'm sorry if the usefulness or context of my question was not clearly spelled out.

    To get back on topic, you did provide some great input and value inbetween the side commentary.  Especially in regard to the fact that in the end of the day in this case I'm really after the filename without extension.  I like the usage of ([io.fileinfo]$MyInvocation.MyCommand.Definition).BaseName instead in this case, so thank you for the suggestion.

    If you are still interested the bug I was referring to is one that I had recently submitted referenced in the original post:  https://connect.microsoft.com/PowerShell/feedback/details/797787/myinvocation-mycommand-returns-null-when-used-as-a-param-default-with-cmdletbinding-in-ise

    I'll consider this one closed out and will mark your last response as the answer.  In all seriousness, thank you for all of the suggestions to both you and everyone else.

    Thursday, August 29, 2013 12:08 AM
  • I think you will find in the end that that is not a bug.  The Param statement is not processed inside of the function or script so the value is not set yet.

    To clarify - the Param stataemnet is not executed within the scope of the function but in the outer scope.


    ¯\_(ツ)_/¯


    • Edited by jrv Thursday, August 29, 2013 12:19 AM
    Thursday, August 29, 2013 12:16 AM
  • I am not trying to put you off.  I am saying that you should rely more on others to be able to learn the system.  Use standards and rules as a way of clarifying local issues.

    I also wanted you to more completely pursue a deep understanding of PowerShell.  If you are going to be a standards maker you must first be an expert.

    Years ago I went to work for a company that stuck us with a library of time functions.  The guy who wrote them clearly new little about time standards and less about assembly language. He was an engineer so we were al stuck with hi nightmare until I proved that his code was wrong. We spent a year fixing customer systems.

    Become and expert in all things you are making standards with and for.


    ¯\_(ツ)_/¯

    Thursday, August 29, 2013 12:25 AM
  • I think you will find in the end that that is not a bug.  The Param statement is not processed inside of the function or script so the value is not set yet.

    To clarify - the Param stataemnet is not executed within the scope of the function but in the outer scope.


    ¯\_(ツ)_/¯



    Very valid point, thanks again.  It was the inconsistent behavior between v2, v3, ISE, CLI and then with and without [CmdletBinding()] that brought me to raise it as a bug ultimately.  I would at least expect things to behave the same in all environments.  I really wouldn't amount it to much more than a nuisance, and there are a number of ways to avoid the problem.  Again, I just figured I would raise it for some attention to hopefully at least get it to behave the same no matter what the cause/outcome.
    Thursday, August 29, 2013 1:15 AM
  • I am not trying to put you off.  I am saying that you should rely more on others to be able to learn the system.  Use standards and rules as a way of clarifying local issues.

    I also wanted you to more completely pursue a deep understanding of PowerShell.  If you are going to be a standards maker you must first be an expert.

    Years ago I went to work for a company that stuck us with a library of time functions.  The guy who wrote them clearly new little about time standards and less about assembly language. He was an engineer so we were al stuck with hi nightmare until I proved that his code was wrong. We spent a year fixing customer systems.

    Become and expert in all things you are making standards with and for.


    ¯\_(ツ)_/¯


    Point taken, and I do try to learn as much as possible about most environments I deal with regularly already.  Howerver, no matter how much I ever do learn about any given environment, I would never consider myself an expert.  I feel that there is always more to be learned, and try to take it what I can everyday.  Especially with technology ever changing and evolving.  It's the reason I try to learn from others in the community and come to forums such as this one.  Again, thank you for all of the feedback and deeper insight into things.  I hope no offense was taken by my responses.
    Thursday, August 29, 2013 1:19 AM
  • Note that there are significant difference in behavior between versions due to the version of dotNet and other subtle things.  For the most part, if you follow the rules, you will almost never see these differences.

    ISE and CLI are different by default because CLI is MTA and ISE is STA.  This drastically changes many behaviors in some very subtle ways.  In time you will learn to recognize these and check for this kind of issue.


    ¯\_(ツ)_/¯

    Thursday, August 29, 2013 1:25 AM
  • I hope no offense was taken by my responses.

    No.  I didn't see it as offensive.  You were responding to my little play about things and it was an OK response. I assumed you would get up. 

    I am a big believer in demanding a level of learning from my co-workers and those I supervise.  I rely heavily on them to know as much as possible and to tell me when they think I have missed something.

    Being and 'expert' and striving to become expert are two completely different things.  Striving to become expert in something is more valuable in my view.

    Good luck.


    ¯\_(ツ)_/¯

    Thursday, August 29, 2013 1:41 AM
  • ISE and CLI are different by default because CLI is MTA and ISE is STA.  This drastically changes many behaviors in some very subtle ways.  In time you will learn to recognize these and check for this kind of issue.

    I thought the default in v3 was that both are STA by default now?  The difference between ISE and CLI only seemed to start with v3 as the code worked the same with both in v2 from what testing I've done. 

    It's relatively simple to avoid the problem once you are aware of it existing.  Really just need to comment out [CmdletBinding()] if testing something via the ISE directly.  Which typically is fine as you normally aren't passing params when executing a test in ISE.  Everything works fine from CLI and you can still make use of Verbose, etc. Again it's just the odd difference in results between environments that threw me enough to bring some attention to it.


    • Edited by sgrinker Thursday, August 29, 2013 2:34 PM
    Thursday, August 29, 2013 2:33 PM
  • I thought the default in v3 was that both are STA by default now?


    Yep, that's true.  You can verify this in whatever console / ISE you're running with the following command:

    [System.Threading.Thread]::CurrentThread.GetApartmentState()

    Thursday, August 29, 2013 2:41 PM
  • I can run this code in both on V2 and V3 and it always gives me the same result.

     ([io.fileinfo]$MyInvocation.MyCommand.Definition).BaseName

    And this:

    ([io.fileinfo]$PSCommandPath).BaseName

    What is it that you think is not working the same.  The first line works on V2/V3 CLI/ISE.


    ¯\_(ツ)_/¯

    Thursday, August 29, 2013 3:10 PM
  • Create a new script with the following and save it...

    [CmdletBinding()]
    Param(
         $CurrentPath = $PSScriptRoot,
         $CurrentPath2 = $Script:MyInvocation.MyCommand.Path
    ) 
    Write-Host $CurrentPath
    Write-Host $CurrentPath2

    Execute (Run/F5) the script while it is opened in ISE.  Execute the script from the CLI.  Do this for both v2 and v3.  The first test both will return $Null, while it will return the path correctly in other tests.

    NOTE: Calling the script from the CLI frame within ISE works fine. It's only failing if you run the script while it's opened by selecting F5 or clicking run. Which is something done while working on the script to test things out, etc. I get that you aren't normally firing off scripts this way, but the odd result leads to some confusion when trying to test things out.
    • Edited by sgrinker Thursday, August 29, 2013 3:23 PM
    Thursday, August 29, 2013 3:20 PM
  • Create a new script with the following and save it...

    [CmdletBinding()]
    Param(
         $CurrentPath = $PSScriptRoot,
         $CurrentPath2 = $Script:MyInvocation.MyCommand.Path
    ) 
    Write-Host $CurrentPath
    Write-Host $CurrentPath2

    Execute (Run/F5) the script wile it is opened in ISE.  Execute the script from the CLI.  Do this for both v2 and v3.  The first test both will return $Null, while it will return the path correctly in other tests.

    I already noted that using those variables in a bound parameter will not work because, as I n almost all languages, the defaults can only be set from the outer scope.  The Params is parsed to prep the script before the script is actually executed.  I recommend not using script level variables in a Param statement. 

    Consider that evaluating either of those variables/object at a prompt will always return a null.

    In compiled languages we have the same issue when setting defaults for arguments.  It is true inVB6 and VB.Net.  You must use either a static value or reference a variable that already exists and will evaluate to a value other than null.  I suspect that in V2 this may not have been checked for so, at time, it would appear to work and at other times it would be trying to assign null to a default.

    I cannot state absolutely how this works.  You could post on the WMF website or blog to get a more complete answer.

    On all of my V3 systems your test code does work and, so far, I have not gotten it to fail. m Placing the same code in a module or calling from one script to the next may cause other issues.  I don't know.

    Is it possible you are missing some service packs and patches for the Net Framework?


    ¯\_(ツ)_/¯

    Thursday, August 29, 2013 3:30 PM
  • Create a new script with the following and save it...

    [CmdletBinding()]
    Param(
         $CurrentPath = $PSScriptRoot,
         $CurrentPath2 = $Script:MyInvocation.MyCommand.Path
    ) 
    Write-Host $CurrentPath
    Write-Host $CurrentPath2

    Execute (Run/F5) the script while it is opened in ISE.  Execute the script from the CLI.  Do this for both v2 and v3.  The first test both will return $Null, while it will return the path correctly in other tests.

    NOTE: Calling the script from the CLI frame within ISE works fine. It's only failing if you run the script while it's opened by selecting F5 or clicking run. Which is something done while working on the script to test things out, etc. I get that you aren't normally firing off scripts this way, but the odd result leads to some confusion when trying to test things out.

    Ok - if the script is loaded and executed with the run facility it does behave differently.  Of course I am not sure what the intentions of the run facility are except to help with debugging and editing scripts.

    Post in the WMF blog to see what they say.

    I bet it is about using those variables in a Param default.


    ¯\_(ツ)_/¯

    Thursday, August 29, 2013 3:35 PM
  • Oddly it behaves the same on all of our v3 systems here even those fully patched.  I've had others at external locations verify the same results.  Just to confirm you are running the loaded script in ISE and not calling it from the CLI, correct?

    You make a fair point about when the Param block is executed, and it not being a good practice to call script level variables from within the param block.

    I still find the different behavior between execution environments to be odd at best, and I can't say I can explain it either.  This definitely isn't "mission critical" here, just something odd that I thought I'd float over to the PS team.  I'm by no means saying "stop everything this is the most important find in history!!", but it might potentially be of some value to note what is going on and why it's different.  Not sure why you are getting different results either.

    Thursday, August 29, 2013 3:43 PM
  • Create a new script with the following and save it...

    [CmdletBinding()]
    Param(
         $CurrentPath = $PSScriptRoot,
         $CurrentPath2 = $Script:MyInvocation.MyCommand.Path
    ) 
    Write-Host $CurrentPath
    Write-Host $CurrentPath2

    Execute (Run/F5) the script while it is opened in ISE.  Execute the script from the CLI.  Do this for both v2 and v3.  The first test both will return $Null, while it will return the path correctly in other tests.

    NOTE: Calling the script from the CLI frame within ISE works fine. It's only failing if you run the script while it's opened by selecting F5 or clicking run. Which is something done while working on the script to test things out, etc. I get that you aren't normally firing off scripts this way, but the odd result leads to some confusion when trying to test things out.

    If it's just setting a default in the param block that isn't working, you should be able to work around that like this:

    [CmdletBinding()]
    Param(
         $Path = $null
    )
    
    if ($Path -eq $null)
    {
        $Path = $MyInvocation.MyCommand.Path
    }
    

    This way the references to $MyInvocation happen inside your script or function's scope, not wherever the code in the param block happens to be evaluated.
    Thursday, August 29, 2013 3:45 PM
  • Yes, thank you!  That is actually more or less how I built around it for some of our older scripts that used to work in v2.  Basically just checked the value and updated it later to the default if needed.  Again if you aren't expecting $Null in that scenario when testing the script in ISE it can lead to a handful of errors due to the $Null value.  Otherwise things work fine when running the script normally.

    The idea was to allow for the person executing to pass along a different value, but still have a default value which is the local directory to the script.

    Thursday, August 29, 2013 3:50 PM
  • For anyone that actually cares at this point and is potentially looking for something similar, I have found $MyInvocation.ScriptName to be more reliable for the purposes here.  This is especially true if you are looking to use a Module at all, since this will return the calling scriptname.  Also Scopes don't seem to cause as much headache with this route either.  It seems to work reliably in different environments, and only returns $Null if called from the CLI or not from within a saved script.

    Granted to be fair, I'm still trying to find a good source for a solid definition of $MyInvocation.ScriptName to be sure it's reliable.

    JRV's recomendation of using ([io.fileinfo]$MyInvocation.MyCommand.Definition).BaseName or just $MyInvocation.MyCommand.Definition does also work, but can get a little rough depending on what is calling the function/module.

    Again, both work... it just depends on what you are after.  Just thought I would share recent findings if anyone is interested.  I'd be curious if anyone has a good reference for more details on $MyInvocation.ScriptName, since as I mentioned documentation appears to be light on what I can find thus far.


    • Marked as answer by sgrinker Wednesday, September 04, 2013 4:56 PM
    • Edited by sgrinker Wednesday, September 04, 2013 5:03 PM
    Wednesday, September 04, 2013 4:56 PM