How to run a PowerShell script with verbose output?

Question

I'm wondering if there's a way to run a PowerShell script such that both the commands and the output of each line of the script are printed. For example, in Bash you would write bash -x myscript or place a set -x at the top of your script. In Batch, you would omit the @echo off traditionally left at the top of your script. Does PowerShell have an equivalent of these constructs?

Things I've tried: Running powershell -? | sls verbose, which turned up nothing.

Answer 1

Just goes to show, @JamesKo, if you ask the wrong question you get the wrong answer :-(. Several people put forth good-faith answers here based on (a) lack of Linux exposure and (b) your use of the term verbose. In the following I will walk you through how Linux relates to PowerShell on this topic, but feel free to jump to the answer at the end if you are in a hurry. :-)

Background

In PowerShell, verbose has a very specific meaning which the PowerShell man page is even rather vague about:

Displays detailed information about the operation performed by the command. This information resembles the information in a trace or in a transaction log. This parameter works only when the command generates a verbose message.

It even sounds like what you want... but let's compare that to the Linux documentation for set -x which, depending on your flavor of Linux, could be this (from man-pages project)...

The shell shall write to standard error a trace for each command after it expands the command and before it executes it.

or this (from gnu)...

Print a trace of simple commands, for commands, case commands, select commands, and arithmetic for commands and their arguments or associated word lists after they are expanded and before they are executed.

The very first line of your question clearly and concisely agrees with these. But verbose in PowerShell is different. In a nutshell, turning on verbose mode (be it with the -Verbose command line switch or the $VerbosePreference variable) simply enables output from the verbose stream to the console. (Just like Linux offers two streams, stdout and stderr, PowerShell offers multiple streams: output stream, error stream, warning stream, verbose stream, and debug stream. You work with these streams in an identical fashion to that of Linux--you can even use, e.g., commands 4>&1 to merge the verbose stream to stdout, for example. (You can read more about PowerShell's multiple output streams in the Basic Writing Streams section of PowerShell One-Liners: Accessing, Handling and Writing Data and a good quick reference is the Complete Guide to PowerShell Punctuation.)

The Answer

The Set-PSDebug command will give you bash-equivalent tracing. You can even adjust the tracing detail with the -Trace parameter. First, here's the control, before using Set-PSDebug:

PS> Get-PSDepth
0

With a value of 1 you get each line of code as it executes, e.g.:

PS> Set-PSDebug -Trace 1
PS> Get-PSDepth
DEBUG:    1+  >>>> Get-PSDepth
DEBUG:  141+  >>>> {
DEBUG:  142+   >>>> $nest = -1
DEBUG:  143+   >>>> $thisId = $pid
DEBUG:  144+  while ( >>>> (ps -id $thisId).Name -eq 'powershell') {
DEBUG:  145+    >>>> $thisId = (gwmi win32_process -Filter "processid='$thisId'").ParentProcessId
DEBUG:  146+    >>>> $nest++
DEBUG:  144+  while ( >>>> (ps -id $thisId).Name -eq 'powershell') {
DEBUG:  148+   >>>> $nest
0
DEBUG:  149+  >>>> }

With a value of 2 you also get variable assignments and code paths:

PS> Set-PSDebug -Trace 2
PS> Get-PSDepth
DEBUG:    1+  >>>> Get-PSDepth
DEBUG:     ! CALL function '<ScriptBlock>'
DEBUG:  141+  >>>> {
DEBUG:     ! CALL function 'Get-PSDepth'  (defined in file 'C:\Users\msorens\Documents\WindowsPowerShell\profile.ps1')
DEBUG:  142+   >>>> $nest = -1
DEBUG:     ! SET $nest = '-1'.
DEBUG:  143+   >>>> $thisId = $pid
DEBUG:     ! SET $thisId = '9872'.
DEBUG:  144+  while ( >>>> (ps -id $thisId).Name -eq 'powershell') {
DEBUG:  145+    >>>> $thisId = (gwmi win32_process -Filter "processid='$thisId'").ParentProcessId
DEBUG:     ! SET $thisId = '10548'.
DEBUG:  146+    >>>> $nest++
DEBUG:     ! SET $nest = '0'.
DEBUG:  144+  while ( >>>> (ps -id $thisId).Name -eq 'powershell') {
DEBUG:  148+   >>>> $nest
0
DEBUG:  149+  >>>> }

Those are traces of a simple cmdlet I wrote called Get-PSDepth. It prints the commands, assignments, etc. with the DEBUG prefix, intermixed with the actual output, which in this case is the single line containing just 0.

Answer 2

If you're using write-verbose in your scripts this will happen automatically,

However, if you need to manually write verbose output from your functions, you'll need to manually check that each function is called with the verbose flag. This can be done by checking$PSCmdlet.MyInvocation.BoundParameters["Verbose"] from inside your function.

Answer 3

You can always use the below in your script.

$VerbosePreference="Continue"

Note: You have to open the shell in elevated mode.

Below screenshot is for reference.

Hope it helps.

Answer 4

This actually is very easy every PowerShell CMDLET has a built in Verbose tag. All you have to do for example:

Test-Connection -ComputerName www.google.com -Verbose

That is it. I hope this helps

Answer 5

To let PowerShell script able to receive parameters from arguments/command line, need to add [CmdletBinding()] param () even though do not have any parameter.

Example script: Test-Output.ps1

[CmdletBinding()] param ()
Write-Host "Test output on OS $($Env:OS)"
Write-Verbose "Test VERBOSE output on OS $($Env:OS)"

1. Execute the script in PowerShell:

PS C:\> .\Test-Output.ps1 -Verbose

2. Execute the script in PowerShell on Linux:

/$ pwsh
PS /> ./Test-Output.ps1 -Verbose

3. Execute the script using PowerShell.exe on Windows:

C:\> powershell.exe Test-Output.ps1 -Verbose

4. Execute the script using pwsh.exe PowerShell Core on Windows:

C:\> pwsh.exe Test-Output.ps1 -Verbose

5. Execute the script using pwsh PowerShell Core on Linux:

/$ pwsh Test-Output.ps1 -Verbose

Sample output on Windows:

Test output on OS Windows_NT
VERBOSE: Test VERBOSE output on OS Windows_NT

Sample output on Linux:

Test output on OS 
VERBOSE: Test VERBOSE output on OS 

Answer 6

^{Note: This answer was originally posted in response to the duplicate question at Windows Powershell needs to print out information for a particular command regardless of whether it successfully executed or Not.}

To complement and elaborate on Michael Sorens' helpful answer:

With limitations, you can use Set-PSDebug -Trace 1 to let PowerShell echo script statements for you before they are executed; however, this is more like bash's set -o verbose / set -v option rather than set -o xtrace / set -x, in that the commands echoed are unexpanded; details follow:

# Start tracing statements.
Set-PSDebug -Trace 1

try 
{

  # Sample command
  cmd /c echo 'hi there' $HOME

}
finally {
  Set-PSDebug -Trace 0 # Turn tracing back off.
}

The above yields:

DEBUG:    4+  >>>> cmd /c echo 'hi there' $HOME
"hi there" C:\Users\jdoe
DEBUG:    6+  >>>> Set-PSDebug -Trace 0 # Turn tracing off.

While this approach requires little extra effort, its limitations are:

• You don't get to control the prefix of the tracing statements. (e.g. DEBUG: 4+ >>>> , where 4 is the line number.

• Turning tracing back off invariably also produces a tracing statement.

• There's no way to capture or suppress the tracing output - it invariably prints to the host (console); however, you can capture it from outside PowerShell, via PowerShell's CLI - see this answer.

• As of PowerShell 7.2, commands that span multiple lines using line continuation only have their first line echoed (see GitHub issue #8113).

• Perhaps most importantly, the statements being echoed are their literal source-code representations and can therefore contain unexpanded variable references and expressions, such as $HOME in the example above.

  • GitHub issue #9463 proposes that expanded values (i.e., variables and expressions replaced by their values), as you would get with set -x in bash, for instance.
  • While this is feasible for calls to external programs - whose arguments are invariably strings anyway, the challenge is that calls to PowerShell commands supports arguments of arbitrary .NET types, not all of which have a faithful string-literal representation; that said, even a for-human-eyeballs-only string representation is arguably preferable to unexpanded values.

---

If you need to see expanded argument values and/or control the output format / target:

Note:

• While Invoke-Expression (iex) should generally be avoided, due to its inherent security risks and because better, safer options are usually available, it does offer a solution here - as always, be sure that you fully control what goes into the string passed to Invoke-Expression, to avoid potential injection of unwanted commands.

• The solution requires you to construct the string to pass to Invoke-Expression with up-front expansion (string-interpolation), so that the resulting command line, when executed, only contains literal arguments, so that echoing the command line paints the full picture of what executable is invoked and what its arguments are.

  • As noted above, this is only robustly possible if you're calling an external program, such as msbuild.

First, define a helper function that accepts a command-line string, echoes it, and then executes it via Invoke-Expression:

# !! IMPORTANT:
# !! Only pass *trusted* strings to this function - the
# !! argument is blindly passed to Invoke-Expression.
function Invoke-AfterEchoing {
  param([string] $commandLine)

  # Echo the command line to be executed,
  # using the verbose output stream in this example:
  Write-Verbose -Verbose "Executing: $commandLine"

  Invoke-Expression $commandLine

}

Now you can construct your command-line strings and pass them to the helper function:

Invoke-AfterEchoing @"
& "$msbuild" .\blabBlah.csproj /t:Clean
"@


Invoke-AfterEchoing @"
& "$msbuild" .\blabBlah.csproj /t:Build /p:Configuration=Dev
"@

Note:

• A expandable here-string (@"<newline>...<newline>"@) is used to simplify the string-internal quoting.

  • The expandable form is chosen to ensure that the executable path and all arguments are expanded up front and therefore embedded as their literal values in the resulting string, so that echoing the string will show all actual values.

• &, the call operator, is used to invoke msbuild, which is syntactically necessary, given that its path is passed quoted, which in turn is necessary if $msbuild contains a path with spaces.

The output will look something like this:

VERBOSE: Executing: & "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin" .\blabBlah.csproj /t:Clean
# ... (output)

VERBOSE: Executing: & "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin" .\blabBlah.csproj /t:Build /p:Configuration=Dev
# ... (output)