Get-CimInstance -ComputerName $pc -Class Win32_UserProfile | Where-Object { $_.LocalPath.split('\')[-1] -eq $compare } | Remove-CimInstance
Because some system profiles have empty values for LocalPath, I get the following:
You cannot call a method on a null-valued expression. At line:52 char:88
Where-Object { $_.LocalPath.split('')[-1] -eq $compare })
Any way either first check for empty value and skip to next?
ty
In PowerShell (Core) 7.1 and above, you can use the null-conditional operator, ?.:
Get-CimInstance -ComputerName $pc -Class Win32_UserProfile |
Where-Object { $_.LocalPath?.split('\')[-1] -eq $compare } |
Remove-CimInstance
As a general caveat:
?. works as expected with properties, with variables it unfortunately and unexpectedly requires the variable name to be enclosed in {...}, because - surprisingly - ? is a legal character in a variable name.Set-StrictMode -Version 2; $foo = $null; ${foo}?.ToUpper() works, but using $foo?.ToUpper() instead does not, because PowerShell looks for a variable named $foo? (sic), which doesn't exist. Requesting that this counterintuitive behavior be changed - even though it is technically a breaking change - is the subject of GitHub issue #14025.In Windows PowerShell you can use PowerShell's implicit to-Boolean conversion rules:
Get-CimInstance -ComputerName $pc -Class Win32_UserProfile |
Where-Object { $_.LocalPath -and $_.LocalPath.split('\')[-1] -eq $compare } |
Remove-CimInstance
Due to use of $_.LocalPath as an operand with the -and operator, it is implicitly coerced to a Boolean, and $null is coerced to $false; similarly, an empty string would yield $false - see the bottom section of this answer for a summary of PowerShell's to-Boolean conversion rules.
Since -and short-circuits (as does -or), the RHS expression is never evaluated if $_.LocalPath yields $false, thereby avoiding the error.
Note that -eq has higher precedence than -and (and -or), so no parentheses are needed around the RHS expression - see the conceptual about_Operator_Precedence help topic