2014-11-11 9 views
7

In PowerShell, git checkout viene eseguito senza alcun messaggio di errore. In ISE, mentre gli alambicchi git checkout funzionano, l'ISE fornisce un messaggio di errore.PowerShell ISE genera un errore nel checkout git

> git checkout master 
Your branch is ahead of 'origin/master' by 3 commits. 
(use "git push" to publish your local commits) 
git : Switched to branch 'master' 
At line:1 char:1 
+ git checkout master 
+ ~~~~~~~~~~~~~~~~~~~ 
    + CategoryInfo   : NotSpecified: (Switched to branch 'master':String) [], RemoteException 
    + FullyQualifiedErrorId : NativeCommandError 

Questo non è un grosso problema, perché git checkout funziona ancora. È fastidioso, quindi, mi piacerebbe sapere perché l'ISE si lamenta quando lo standard PowerShell non lo fa, e, soprattutto, come possiamo evitare questo fastidio.

Ho visto Why is Powershell ISE showing errors that Powershell console does not show?, il che spiega che ISE sta semplicemente visualizzando ciò che sta sperimentando la shell normale. Quella risposta non spiega come calmare questo comportamento fastidioso.

+1

sembra che ise reagisca all'output di stderr in cui PowerShell no, forse dare un'occhiata alle risposte a questa domanda: http://stackoverflow.com/questions/1394084/ignoring-an-errorlevel-0-in-windows -powershell Se non vuoi che l'errore venga mostrato puoi reindirizzare stderr a $ null come questo '2> $ null' – Paul

+0

Dovrebbe/Potrebbe essere riscritta questa domanda per rappresentare il fatto che Git usa il flusso di output di errore per molto del suo output (non solo per il checkout), sembra terribile in qualsiasi host (non solo l'ISE)? –

risposta

8

Ci sono alcuni modi per evitare questi errori, nessuno di loro sembra o è "naturale". primo usa errore flusso di reindirizzamento e una certa logica in giro per gli errori:

$out = git ? 2>&1 
if ($?) { 
    $out 
} else { 
    $out.Exception 
} 

In secondo luogo dipende dalla ErrorAction, che è disponibile solo per PowerShell costruisce, quindi abbiamo bisogno di costruire una prima:

& { 
    [CmdletBinding()] 
    param() 

    git ? 
} -ErrorAction SilentlyContinue -ErrorVariable fail 

if ($fail) { 
    $fail.Exception 
} 

In il mio modulo ISEGit lo uso per evitare che le registrazioni degli errori "perdano" all'utente finale in modo incontrollato.

Infine si puo 'risolvere il problema' (beh, sorta fuori ...) facendo in modo è possibile una stringa alla fine:

"$(git ? 2>&1)" 

O qualcosa che avrebbe votato contro in quanto vi lascerà inconsapevoli di eventuali errori effettivi, impostazione globale $ErrorActionPreference a SilentlyContinue - anche se questo non è diverso dal reindirizzamento del flusso di errori a $null.

+0

Qualche possibilità di mostrare un rapido esempio di come la chiameresti nell'esempio 2. –

1

Un profilo pronto versione Funzione-ized di risposta eccellente @ di BartekB ...

function Invoke-Git { 
<# 
.Synopsis 
Wrapper function that deals with Powershell's peculiar error output when Git uses the error stream. 

.Example 
Invoke-Git ThrowError 
$LASTEXITCODE 

#> 
    [CmdletBinding()] 
    param(
     [parameter(ValueFromRemainingArguments=$true)] 
     [string[]]$Arguments 
    ) 

    & { 
     [CmdletBinding()] 
     param(
      [parameter(ValueFromRemainingArguments=$true)] 
      [string[]]$InnerArgs 
     ) 
     C:\Full\Path\To\git.exe $InnerArgs 
    } -ErrorAction SilentlyContinue -ErrorVariable fail @Arguments 

    if ($fail) { 
     $fail.Exception 
    } 

} 

# Could shorten the function name. I instead alias it, for terseness. 
Set-Alias -Name git -Value Invoke-Git 

# Also alias the name with the extension, as it is called by some applications this way. 
Set-Alias -Name git.exe -Value Invoke-Git 
+0

Inoltre ho aggiunto 'Function git() {Invoke-Git @args}' così posso usare 'git' normalmente. – BrunoLM

+1

Potrebbe rinominare la funzione o aliasarla. Aggiungerò la riga alias all'esempio di script. –

+0

La creazione di un alias per 'git.exe' causa un ciclo infinito (perché sul tuo' Invoke-Git' lo usi). Aliasing semplicemente 'git' va bene e non causa problemi. – BrunoLM

0

Come specificato here, aggiungendo -q dopo il comando di tranquillità non mostrerà questo tipo di errori.