Skip to main content
added 310 characters in body
Source Link
mklement0
  • 452.5k
  • 68
  • 728
  • 988
# PowerShell 7+ only # Windows Get-Content data.txt | Tee-Object \\.\CON | data_processor.exe # Unix-like platforms (Linux, macOS) Get-Content data.txt | Tee-Object /dev/tty | data_processor.exe # Platform-agnostic # See coming future improvement below (-Host) Get-Content data.txt | Tee-Object ($IsWindows ? '\\.\CON': '/dev/tty') | data_processor.exe 

Note:

  • GitHub issue #19827 is a green-lit, but as yet (as of PowerShell (Core) 7.3.x) unimplemented improvement that will allow simplifying
    ($IsWindows ? '\\.\CON': '/dev/tty') to -Host.
# PowerShell 7+ only # Windows Get-Content data.txt | Tee-Object \\.\CON | data_processor.exe # Unix-like platforms (Linux, macOS) Get-Content data.txt | Tee-Object /dev/tty | data_processor.exe # Platform-agnostic Get-Content data.txt | Tee-Object ($IsWindows ? '\\.\CON': '/dev/tty') | data_processor.exe 
# PowerShell 7+ only # Windows Get-Content data.txt | Tee-Object \\.\CON | data_processor.exe # Unix-like platforms (Linux, macOS) Get-Content data.txt | Tee-Object /dev/tty | data_processor.exe # Platform-agnostic # See coming future improvement below (-Host) Get-Content data.txt | Tee-Object ($IsWindows ? '\\.\CON': '/dev/tty') | data_processor.exe 

Note:

  • GitHub issue #19827 is a green-lit, but as yet (as of PowerShell (Core) 7.3.x) unimplemented improvement that will allow simplifying
    ($IsWindows ? '\\.\CON': '/dev/tty') to -Host.
added 16 characters in body
Source Link
mklement0
  • 452.5k
  • 68
  • 728
  • 988

To complement zett42's helpful answer:

If you're running PowerShell (Core) 7+, you can pass the file path that represents the terminal (console) to the (positionally implied) -FilePath parameter (in Windows PowerShell, this causes an error, unfortunately - see bottom section):

# PowerShell 7+ only # Windows Get-Content data.txt | Tee-Object CON\\.\CON | data_processor.exe # Unix-like platforms (Linux, macOS) Get-Content data.txt | Tee-Object /dev/tty | data_processor.exe # Platform-agnostic Get-Content data.txt | Tee-Object ($IsWindows ? 'CON''\\.\CON': '/dev/tty') | data_processor.exe 

This passes all data through while also printing it to the terminal (console), richly formatted, as usual, as it becomes available - unlike with the Tee-Object -Variable approach, which requires collecting all output in memory first (which is a concern both in terms of output timing and memory consumption).


Windows PowerShell solution: Custom proxy (wrapper) function Tee-Host wraps Out-Host while also passing its input through; use it instead of Tee-Object:

function Tee-Host { [CmdletBinding()] param( [Parameter(ValueFromPipeline)] $InputObject ) begin { $scriptCmd = { Out-Host } $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin) $steppablePipeline.Begin($PSCmdlet) } process { # Pass to Out-Host, and therefore to the host (terminal) $steppablePipeline.Process($InputObject) # Pass through (to the success stream) $InputObject } end { $steppablePipeline.End() } } 
  • In effect, Tee-Host behaves like Tee-Object CON\\.\CON / Tee-Object /dev/tty in PowerShell 7+, where Tee-Host works too.

  • Even in PowerShell 7+ Tee-Host may be preferable, because it uses colored output unconditionally, whereas the coloring behavior of Tee-Object CON\\.\CON / Tee-Object /dev/tty depends on the value of $PSStyle.OutputRendering

It is the use of a proxy function with a steppable pipeline wrapping Out-Host that ensures that the to-host formatted output looks the same as when the input is directly sent to the host.

To complement zett42's helpful answer:

If you're running PowerShell (Core) 7+, you can pass the file path that represents the terminal (console) to the (positionally implied) -FilePath parameter (in Windows PowerShell, this causes an error, unfortunately - see bottom section):

# PowerShell 7+ only # Windows Get-Content data.txt | Tee-Object CON | data_processor.exe # Unix-like platforms (Linux, macOS) Get-Content data.txt | Tee-Object /dev/tty | data_processor.exe # Platform-agnostic Get-Content data.txt | Tee-Object ($IsWindows ? 'CON': '/dev/tty') | data_processor.exe 

This passes all data through while also printing it to the terminal (console), richly formatted, as usual, as it becomes available - unlike with the Tee-Object -Variable approach, which requires collecting all output in memory first (which is a concern both in terms of output timing and memory consumption).


Windows PowerShell solution: Custom proxy (wrapper) function Tee-Host wraps Out-Host while also passing its input through; use it instead of Tee-Object:

function Tee-Host { [CmdletBinding()] param( [Parameter(ValueFromPipeline)] $InputObject ) begin { $scriptCmd = { Out-Host } $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin) $steppablePipeline.Begin($PSCmdlet) } process { # Pass to Out-Host, and therefore to the host (terminal) $steppablePipeline.Process($InputObject) # Pass through (to the success stream) $InputObject } end { $steppablePipeline.End() } } 
  • In effect, Tee-Host behaves like Tee-Object CON / Tee-Object /dev/tty in PowerShell 7+, where Tee-Host works too.

  • Even in PowerShell 7+ Tee-Host may be preferable, because it uses colored output unconditionally, whereas the coloring behavior of Tee-Object CON / Tee-Object /dev/tty depends on the value of $PSStyle.OutputRendering

It is the use of a proxy function with a steppable pipeline wrapping Out-Host that ensures that the to-host formatted output looks the same as when the input is directly sent to the host.

To complement zett42's helpful answer:

If you're running PowerShell (Core) 7+, you can pass the file path that represents the terminal (console) to the (positionally implied) -FilePath parameter (in Windows PowerShell, this causes an error, unfortunately - see bottom section):

# PowerShell 7+ only # Windows Get-Content data.txt | Tee-Object \\.\CON | data_processor.exe # Unix-like platforms (Linux, macOS) Get-Content data.txt | Tee-Object /dev/tty | data_processor.exe # Platform-agnostic Get-Content data.txt | Tee-Object ($IsWindows ? '\\.\CON': '/dev/tty') | data_processor.exe 

This passes all data through while also printing it to the terminal (console), richly formatted, as usual, as it becomes available - unlike with the Tee-Object -Variable approach, which requires collecting all output in memory first (which is a concern both in terms of output timing and memory consumption).


Windows PowerShell solution: Custom proxy (wrapper) function Tee-Host wraps Out-Host while also passing its input through; use it instead of Tee-Object:

function Tee-Host { [CmdletBinding()] param( [Parameter(ValueFromPipeline)] $InputObject ) begin { $scriptCmd = { Out-Host } $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin) $steppablePipeline.Begin($PSCmdlet) } process { # Pass to Out-Host, and therefore to the host (terminal) $steppablePipeline.Process($InputObject) # Pass through (to the success stream) $InputObject } end { $steppablePipeline.End() } } 
  • In effect, Tee-Host behaves like Tee-Object \\.\CON / Tee-Object /dev/tty in PowerShell 7+, where Tee-Host works too.

  • Even in PowerShell 7+ Tee-Host may be preferable, because it uses colored output unconditionally, whereas the coloring behavior of Tee-Object \\.\CON / Tee-Object /dev/tty depends on the value of $PSStyle.OutputRendering

It is the use of a proxy function with a steppable pipeline wrapping Out-Host that ensures that the to-host formatted output looks the same as when the input is directly sent to the host.

added 210 characters in body
Source Link
mklement0
  • 452.5k
  • 68
  • 728
  • 988

To complement zett42's helpful answer:

If you're running PowerShell (Core) 7+, you can pass the file path that represents the terminal (console) to the (positionally implied) -FilePath parameter (in Windows PowerShell, this causes an error, unfortunately - see bottom section):

# PowerShell 7+ only # Windows Get-Content data.txt | Tee-Object CON | data_processor.exe # Unix-like platforms (Linux, macOS) Get-Content data.txt | Tee-Object /dev/tty | data_processor.exe # Platform-agnostic Get-Content data.txt | Tee-Object ($IsWindows ? 'CON': '/dev/tty') | data_processor.exe 

This passes all data through while also printing it topasses all data through while also printing it to the terminal (console), richly formatted, as usual, as it becomes available - unlike with the terminalTee-Object -Variable approach, which requires collecting all output in memory first (consolewhich is a concern both in terms of output timing and memory consumption), richly formatted, as usual.


Windows PowerShell solution: Custom proxy (wrapper) function Tee-Host wraps Out-Host while also passing its input through; use it instead of Tee-Object:

function Tee-Host { [CmdletBinding()] param( [Parameter(ValueFromPipeline)] $InputObject ) begin { $scriptCmd = { Out-Host } $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin) $steppablePipeline.Begin($PSCmdlet) } process { # Pass to Out-Host, and therefore to the host (terminal) $steppablePipeline.Process($InputObject) # Pass through (to the success stream) $InputObject } end { $steppablePipeline.End() } } 
  • In effect, Tee-Host behaves like Tee-Object CON / Tee-Object /dev/tty in PowerShell 7+, where Tee-Host works too.

  • Even in PowerShell 7+ Tee-Host may be preferable, because it uses colored output unconditionally, whereas the coloring behavior of Tee-Object CON / Tee-Object /dev/tty depends on the value of $PSStyle.OutputRendering

It is the use of a proxy function with a steppable pipeline wrapping Out-Host that ensures that the to-host formatted output looks the same as when the input is directly sent to the host.

To complement zett42's helpful answer:

If you're running PowerShell (Core) 7+, you can pass the file path that represents the terminal (console) to the (positionally implied) -FilePath parameter (in Windows PowerShell, this causes an error, unfortunately - see bottom section):

# PowerShell 7+ only # Windows Get-Content data.txt | Tee-Object CON | data_processor.exe # Unix-like platforms (Linux, macOS) Get-Content data.txt | Tee-Object /dev/tty | data_processor.exe # Platform-agnostic Get-Content data.txt | Tee-Object ($IsWindows ? 'CON': '/dev/tty') | data_processor.exe 

This passes all data through while also printing it to the terminal (console), richly formatted, as usual.


Windows PowerShell solution: Custom proxy (wrapper) function Tee-Host wraps Out-Host while also passing its input through; use it instead of Tee-Object:

function Tee-Host { [CmdletBinding()] param( [Parameter(ValueFromPipeline)] $InputObject ) begin { $scriptCmd = { Out-Host } $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin) $steppablePipeline.Begin($PSCmdlet) } process { # Pass to Out-Host, and therefore to the host (terminal) $steppablePipeline.Process($InputObject) # Pass through (to the success stream) $InputObject } end { $steppablePipeline.End() } } 
  • In effect, Tee-Host behaves like Tee-Object CON / Tee-Object /dev/tty in PowerShell 7+, where Tee-Host works too.

  • Even in PowerShell 7+ Tee-Host may be preferable, because it uses colored output unconditionally, whereas the coloring behavior of Tee-Object CON / Tee-Object /dev/tty depends on the value of $PSStyle.OutputRendering

It is the use of a proxy function with a steppable pipeline wrapping Out-Host that ensures that the to-host formatted output looks the same as when the input is directly sent to the host.

To complement zett42's helpful answer:

If you're running PowerShell (Core) 7+, you can pass the file path that represents the terminal (console) to the (positionally implied) -FilePath parameter (in Windows PowerShell, this causes an error, unfortunately - see bottom section):

# PowerShell 7+ only # Windows Get-Content data.txt | Tee-Object CON | data_processor.exe # Unix-like platforms (Linux, macOS) Get-Content data.txt | Tee-Object /dev/tty | data_processor.exe # Platform-agnostic Get-Content data.txt | Tee-Object ($IsWindows ? 'CON': '/dev/tty') | data_processor.exe 

This passes all data through while also printing it to the terminal (console), richly formatted, as usual, as it becomes available - unlike with the Tee-Object -Variable approach, which requires collecting all output in memory first (which is a concern both in terms of output timing and memory consumption).


Windows PowerShell solution: Custom proxy (wrapper) function Tee-Host wraps Out-Host while also passing its input through; use it instead of Tee-Object:

function Tee-Host { [CmdletBinding()] param( [Parameter(ValueFromPipeline)] $InputObject ) begin { $scriptCmd = { Out-Host } $steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin) $steppablePipeline.Begin($PSCmdlet) } process { # Pass to Out-Host, and therefore to the host (terminal) $steppablePipeline.Process($InputObject) # Pass through (to the success stream) $InputObject } end { $steppablePipeline.End() } } 
  • In effect, Tee-Host behaves like Tee-Object CON / Tee-Object /dev/tty in PowerShell 7+, where Tee-Host works too.

  • Even in PowerShell 7+ Tee-Host may be preferable, because it uses colored output unconditionally, whereas the coloring behavior of Tee-Object CON / Tee-Object /dev/tty depends on the value of $PSStyle.OutputRendering

It is the use of a proxy function with a steppable pipeline wrapping Out-Host that ensures that the to-host formatted output looks the same as when the input is directly sent to the host.

added 112 characters in body
Source Link
mklement0
  • 452.5k
  • 68
  • 728
  • 988
Loading
deleted 2 characters in body
Source Link
mklement0
  • 452.5k
  • 68
  • 728
  • 988
Loading
added 656 characters in body
Source Link
mklement0
  • 452.5k
  • 68
  • 728
  • 988
Loading
added 838 characters in body
Source Link
mklement0
  • 452.5k
  • 68
  • 728
  • 988
Loading
edited body
Source Link
mklement0
  • 452.5k
  • 68
  • 728
  • 988
Loading
Source Link
mklement0
  • 452.5k
  • 68
  • 728
  • 988
Loading