1

I'm trying to clone a Github repo.

Function CloneRepo{
    $solnFolder = -join($outputDir,"\", $newSolutionName)
    git clone -b master "https://github.com/sukesh-y/Stratum.git" $solnFolder
}

$newSolutionName = "MyCompany"
$outputDir = "D:\Test"
CloneRepo

This does clone the repo but there is an error in console.
When I execute the script, it throws the error. After many seconds, it shows the Uploading files progress.

enter image description here

enter image description here

I'm running Windows PowerShell ISE with Admin privileges. What is this error and how can I avoid it.

sukesh
  • 2,379
  • 12
  • 56
  • 111
  • 1
    You are getting a Remote Exception. You are trying to write to the remote folder which needs an Admin. Start PS by right click PS shortcut and select Run As Admin. Also you would need to replace the colon in the path with a dollar sign : "D$\Test" – jdweng Apr 06 '23 at 11:32
  • @jdweng Sorry forgot to mention, but it is with admin privileges. The $ did not work – sukesh Apr 06 '23 at 12:14
  • Any idea why you are getting the RemoteException? – jdweng Apr 06 '23 at 12:37
  • @jdweng, neither remoting nor network shares are involved here. That the word `RemoteException` shows up in the error message - which isn't a true error message - is an unfortunate fact of life when using the PowerShell ISE, which is best avoided these days. – mklement0 Apr 06 '23 at 13:19

1 Answers1

2

tl;dr

  • The obsolescent PowerShell ISE is ill-suited for running external programs such as git: it inappropriately surfaces stderr output as PowerShell errors and lacks proper terminal support in general.

    • Fortunately, these problems do not exist in regular console windows, Windows Terminal, or in Visual Studio Code's integrated terminal.

    • However, even there stderr lines surface and print as PowerShell errors in the output from remoting calls, and you can use the techniques below to prevent that. The unexpected as-error formatting is less problematic when calling from PowerShell (Core) 7+, because only the stderr line text prints in red, whereas in Windows PowerShell you get the same "noisy", multi-line display for the first stderr line as in the ISE. Also, the $ErrorActionPreference = 'Stop' caveat discussed below applies to remoting too.

  • While you can situationally - suboptimally - work around the problem (see below), you're better off migrating to Visual Studio Code with its PowerShell extension.


Your screenshot implies that you're using the PowerShell ISE.

Among the other reasons not to use it is the case at hand:

  • The ISE inappropriately surfaces stderr output from external programs as if they were PowerShell errors, which is undesired and confusing

    • The fact that the spurious errors surface as RemoteException adds to the confusion.

    • More importantly, if $ErrorActionPreference = 'Stop' is in effect, stderr output will inappropriately abort your script: you can not infer failure of an external-program call from the presence of stderr output; only the exit code matters, which must be checked via automatic $LASTEXITCODE variable.

  • Since external programs only have two output streams at their disposal - stdout and stderr - stderr is used for anything that is not data, which isn't necessarily just actual error messages, but often status information.

    • In the case at hand, git uses stderr to provide status information in the form of an iteratively updated progress display meant to update in place.
    • Because the ISE lacks proper terminal support, each progress update ends up on a separate line.
  • If migrating to Visual Studio Code is not an option, you have three options to deal with the problem, all of them suboptimal:

    • You can ignore the problem, and put up with the visual disruption.

    • You can silence stderr output with 2>$null - which means you'll lose not only the status information, but potentially error messages too:

      # Suppress all stderr output
      git ... 2>$null
      
    • You can merge stderr into PowerShell's success output stream with 2>&1, and convert the ErrorRecord instances that represent the stderr output to strings with % ToString (% is a built-in alias of the ForEach-Object cmdlet):

      # Merge stderr output into the success output stream and stringify.
      # Note: If you *capture* the results, you'll get the stdout and
      #       stderr *combined*.
      git ... 2>&1 | % ToString
      
  • None of these workarounds work well in your particular case (progress display), because the information doesn't print until after the command has finished (except that with the first option the first, verbose error message prints right away).

mklement0
  • 382,024
  • 64
  • 607
  • 775