Why do proxy commands handle errors differently - powershell

For a while, I am maintaining a PowerShell Join-Object cmdlet.
In here I am creating a few proxy commands with default parameters, as FullJoin-Object, Merge-Object and Insert-Object as described here: Proxy Functions: Spice Up Your PowerShell Core Cmdlets.
(In earlier version I was using aliases which could problems if the user creates its own aliases.)
Everything works as expected except that the error handling differs a little between the main command and the proxy command...
Taken the following MVCE, based on the following function:
Function Inverse([Int]$Number) {
Rubbish
Write-Output (1 / $Number)
}
(Where the function Rubbish doesn't exist)
Than I create a proxy function called Reverse0:
$MetaData = [System.Management.Automation.CommandMetadata](Get-Command Inverse)
$Value = [System.Management.Automation.ProxyCommand]::Create($MetaData)
$Null = New-Item -Path Function:\ -Name "Script:Inverse0" -Value $Value -Force
$PSDefaultParameterValues['Inverse0:Number'] = 0 # (Not really required for reproducing the issue)
If I run the original function Reverse 0, I get two errors:
Rubbish : The term 'Rubbish' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:2 char:1
+ Rubbish
+ ~~~~~~~
+ CategoryInfo : ObjectNotFound: (Rubbish:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Attempted to divide by zero.
At line:3 char:1
+ Write-Output (1 / $Number)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], RuntimeException
+ FullyQualifiedErrorId : RuntimeException
If run the proxy command Reverse0 (or Reverse0 0), I get only the first error:
Rubbish : The term 'Rubbish' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At line:2 char:1
+ Rubbish
+ ~~~~~~~
+ CategoryInfo : ObjectNotFound: (Rubbish:String) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : CommandNotFoundException
It seems that something like the $ErrorActionPreference has changed but I checked that and it appears to be the same within both functions.
Is there and explanation for the different behavior?
Is there a way to get a Proxy Command act the same as the original command with respect to error handling?

The code that [System.Management.Automation.ProxyCommand]::Create() generates is currently (PowerShell Core 7.0.0-preview.5) flawed:
It incorrectly propagates statement-terminating errors as script-terminating errors, by using throw rather than $PSCmdlet.ThrowTerminatingError($_) in its catch blocks, causing the function to abort instantly.
If you manually correct these calls, your proxy function should behave as expected.
See this GitHub issue; the linked issue isn't specifically about this behavior, but a change has been green-lighted, and it should include a fix for it.
In concrete terms, for now, you'll have to fix the generated code manually:
Locate all try / catch statements that look like this:
try {
# ...
} catch {
throw
}
and replace them with:
try {
# ...
} catch {
$PSCmdlet.ThrowTerminatingError($_)
}

Related

Use variable for URL in powershell BITS transfer

I have the following in a powershell script:
$src_url = "http://my_server/my_file.zip"
if (!(Test-Path $src_zip))
{
"Downloading $src_url"
Start-BitsTransfer -Source "$src_url" -Destination .\$src_zip
}
The output of which is
Downloading http://my_server/my_file.zip
Start-BitsTransfer : The server name or address could not be resolved
At C:\foo.ps1:18 char:5
+ Start-BitsTransfer -Source "$src_url" -Destination .\$src_zip
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Start-BitsTransfer], Exception
+ FullyQualifiedErrorId : StartBitsTransferCOMException,Microsoft.BackgroundIntelligentTransfer.Management.NewBitsTransferComma
nd
I have tried with, without double and single quotes around the URL. However if I type the URL out directly the name is resolved correctly. What should I do to expand $src_url?
Considering it works with hard-coding URL, the source variable should expand correctly in your syntax.
And from error you pasted, it may due to destination path resolution. Try to use full path in it. Example,
$src_zip = "C:\temp\abc.zip"
Please see if the destination file needs to be removed or you can use force parameter.

How to use a variable in Get-MailboxFolderPermission

I wanted to use a variable for a lawyer's name so I could recycle the same Get-MailboxFolderPermission command, but the syntax doesn't seem to work.
The command by itself would be:
Get-MailboxFolderPermission jdoe:\calendar
But if I try to put "jdoe" in a variable ($lawyer = "jdoe")
and then try to invoke it in the command
Get-MailboxFolderPermission $lawyer:\calendar
it gives an error:
Variable reference is not valid. ':' was not followed by a valid variable name character. Consider using ${} to
delimit the name.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : InvalidVariableReferenceWithDrive
Get-MailboxFolderPermission "$($jdoe):\calendar" doesn't give an error, but it also doesn't produce an accurate output of his calendar permission.
I suspect it has to do with the ":" that is part of the command, but I can't find an article that addresses this particular issue.
Sorry, I just figured it out based on the error.
Get-CalendarPermission ${jdoe}:\calendar works properly.

why is powershell complaining about commented lines?

I have the following comment in a powershell script:
#ERROR: Invoke-RestMethod : The underlying connection was closed: An unexpected error occurred on a send.
#EXPLANATION: PowerShell calls uses TLS 1.0 for web requests by default.
# However, Exchange is expecting a higher level of TLS, so you need to tell PowerShell to use 1.2 instead of the default of TLS 1.0
​#SOLUTION(s):
# [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
when i run the script i get this error:
s : The term 's' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the path is correct and try again.
At ps1:4 char:14
+ ​#SOLUTION(s):
+ ~
+ CategoryInfo : ObjectNotFound: (s:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
why is it complaining about a comment?
if i remove (s) it then complains about SOLUTION itself...
You have it posted in your error log: + ​#SOLUTION(s):
There is a null character before the # in your code to the left of SOLUTION(s):, so it is reading the line into powershell. Just delete the row ​#SOLUTION(s): and retype it.
To check copy-and-paste the line into powershell console, should read out like below:

Remove-Item Vs [System.IO.File]::Delete()

I have the following code in an Azure Runbook:
$pathToDownloadedBlob = 'C:\depId-20150904032522\SevenZipSharp.dll'
if ((Test-Path $pathToDownloadedBlob) -eq $true)
{
try
{
Remove-Item -Path $pathToDownloadedBlob
}
catch
{
write-error "Could not delete $pathToDownloadedBlob. - $($error[0])"
exit
}
}
When I use Remove-Item I get this error:
4/7/2015 2:14:14 PM, Error: Remove-Item : The converted JSON string is in bad format.
At DavidTest:45 char:45
+
+ CategoryInfo : InvalidOperation: (System.Unauthor... Boolean force):ErrorRecord) [Remove-Item],
InvalidOperationException
+ FullyQualifiedErrorId : JsonStringInBadFormat,Microsoft.PowerShell.Commands.RemoveItemCommand
When I use [System.IO.File]::Delete($using:path) instead, I get this error:
4/7/2015 2:22:48 PM, Error: Exception calling "Delete" with "1" argument(s): "Access to the path 'C:\Deployment\SevenZipSharp.dll' is denied."
At DavidTest:46 char:46
+
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : UnauthorizedAccessException
I know I don't have permission to delete the file.
However, why is it complaining about a JSON string when I use Remove-Item?
EDIT:
Note this only happens in Azure Automation. However I wasn't truly able to replicate this in Powershell ISE locally because I have permission to files I wish to delete.
UPDATE:I just realised this is only happening for .dll files. If I try to delete a .7z file it works fine.
I would imagine that this is due to the serialization / deserialization of the object being passed between the PowerShell Workflow context, and the InlineScript Workflow Activity, which runs in a separate process by default.
Are you always passing in a [System.String], or are you sometimes passing in a [System.IO.FileInfo] object? If the latter, then you'll probably want to reference the FullName property, rather than passing in the object itself to Remove-Item.
I'm not 100% sure that this is what you're running into, but it's worth discussing.
By the way, as a best practice, always explicitly name your parameters, so other people understand what you're doing. Your call to Remove-Item doesn't include the -Path parameter, by name, because it's positionally at 0. Of course, this isn't a good thing to take for granted when you're asking for help. Better to be verbose.
Hope this helps at least a bit. By the way, is this problem unique to Azure Automation Runbooks, or does it also exist in locally executed PowerShell Workflows?
Edit: This code seems to work just fine for me locally.
workflow test {
$Path = 'C:\dsc\srv01.xml';
InlineScript { Remove-Item -Path $using:Path; };
}
test

start-job loop how to call second script

Can anyone please suggest me what is wrong - I am calling second script from first so that
I can run the compare in background or parallel, due to bug in IDM software I need to
execute loop two times.
I need to call 5 scripts from my main script ( frist script) so that all five scripts run
parallelly.
First Script -
==================================================
Error message
Attribute cannot be added because it would cause the variable sbtFile with value C to become invalid.
+ CategoryInfo : MetadataError: (:) [Start-Job], ValidationMetadataException
+ FullyQualifiedErrorId : ValidateSetFailure,Microsoft.PowerShell.Commands.StartJobCommand
The command cannot find the job because the CompareCtrlMasterCtrlModelESS name was not found. Verify the value of the Name parameter, and then try the comman
d again.
+ CategoryInfo : ObjectNotFound: (CompareCtrlMasterCtrlModelESS:String) [Wait-Job], PSArgumentException
+ FullyQualifiedErrorId : JobWithSpecifiedNameNotFound,Microsoft.PowerShell.Commands.WaitJobCommand
The command cannot find the job because the CompareCtrlMasterCtrlModelESS name was not found. Verify the value of the Name parameter, and then try the comman
d again.
+ CategoryInfo : ObjectNotFound: (CompareCtrlMasterCtrlModelESS:String) [Receive-Job], PSArgumentException
+ FullyQualifiedErrorId : JobWithSpecifiedNameNotFound,Microsoft.PowerShell.Commands.ReceiveJobCommand
Regards
Naveen
You run Start-Job -Name "CompareCtrlMasterCtrlModelESS" in a loop, so you try to create multiple jobs with the same name. Try Start-Job -Name "CompareCtrlMasterCtrlModelESS$i" (with ordinal suffix).