Forum Discussion
UNCLE!!! Getting lost in the whole Object, Methods, Properties, and $ stuff. Hoping for help.
Noting your update, it seems you've largely got your head around the original question (though correct me if I'm wrong), so I'll keep this one brief.
Noting your Write-Output on line 13, specifically focusing on the variable reference embedded in the string, that's not going to work as you might intuitively thing it will.
PowerShell's default parsing of variables in strings is pretty basic, and where you think you're accessing the the child variable InvocationInfo, and then its property ScriptName, you're not, as PowerShell will only parse the top-level $PSItem - again, this is by default.
To utilise multi-part references, you need to use the subexpression operator: $(). This is in the same spirit of prefixing strings in C# with the dollar sign where it treats the content inside the operator as code.
So, this:
write-output "Name = $PSItem.InvocationInfo.ScriptName"
Will become this:
Write-Output -InputObject ("Name = $($PSItem.InvocationInfo.ScriptName)");
Also, on the topic of $PSItem:
- $PSItem and $_ are interchangeable as they are the same thing: the current object on the pipeline;
- Because of this, you want to be careful as it can change in a heartbeat.
In order to avoid that easy-to-fall-into trap (where the current object changes), I'd suggest doing any of the following in the catch block:
- Assign $_ or $PSItem to a local variable, i.e. $MyError = $_; or
- Refer to the current exception using the native $error array, i.e. $error[0].InvocationInfo.ScriptName, etc.
That way, as you invariably do other things that may result in $_ / $PSItem changing, you're not caught trying to track down not-so-obvious issues like this one.
With what you're doing, tapping into InvocationInfo is the best resource, but purely as an FYI, if you're looking for a quicker way to fetch the script name or path from which it's running, check out the built-in $PSCommandPath (former) and $PSScriptRoot (latter), as these are easier to drop into string for substitution, in commandlets like Join-Path, etc.
As a final note, it's good to see you using throw. I see a lot of people report an error but fail to incorporate any kind of flow control - which you're clearly aware of through using throw.
Cheers,
Lain
- MNtobarSep 19, 2022Copper Contributor
OK. Let me see if I have this straight:
On a Tuesday, if I am wearing my yellow socks, and you are working from home at your stand-up desk it is Y, if you are sitting, or it is a Thursday and my socks don't match, it is N. However there is the case ...
I am sure it all makes sense when it all makes sense. I once understood the similar contortions that are intrinsic to "C" (I am a "C" guy. None of this new-fangled "C#" stuff).