PS 5.1, Get-ComputerInfo generates blank lines at the top

[Query-01]

Reminder, I am a Powershell infant, with little or no experience. Try not to laugh to hardy at the format and attempts of this coding.

THE ISSUE: see the image.
Multiple blank lines at the beginning of the Get-ComputerInfo output. Using the attached image, the left positioned vertical numbering is overlayed with the output of a script that recently ran Get-ComputerInfo; notice the empty-space at lines three and four. This space has been confirmed as coming from Get-CompterInfo, which is generated regardless if run from a ps1 script or the cli:

Cli – Get-computerInfo "OsName", "OSDisplayVersion", "OsVersion", "osinstalldate"

Script.ps1 -- $_info = Get-computerInfo "OsName", "OSDisplayVersion",  "OsVersion", "osinstalldate"
write-output $_info

The second part of this concern, within the image lines three and four begin the initial output –from the script

$_info = Get-computerInfo "OsName", "OSDisplayVersion",  "OsVersion", "osinstalldate"
write-output $_info

… during the same script job, as it runs on the next machine (remoting), the blank lines are gone for the duration; until the script is again initiated from the beginning; evidenced by comparing lines three and four –to- lines eleven and twelve.

The only possible resolve that I have not attempted was Format-Custom, that’s a bit much for this infant to swallow. Besides, I’m not sure what affect, if any, it would have on whatever Get-ComputerInfo has already done.

As posted earlier, these blank lines only happen during the first run on the first machine. Please don’t fix the code, instead I’m requesting the required articles to read, that will teach –how to get this done. I 've already tried, while reading along with the respective help file, the following: Write-Output and Write-Host. At this point I feel like I’m driving on a rural-road with no moon or head-light’s;

your thoughts?

[krzydoug]

I’ll keep in mind you are a powershell infant, if you keep in mind we are not mind readers, nor can we see your screen. You clearly have code in your script that you are not showing here. Please share the exact code we can run to reproduce your issue, and I’m certain someone will have a solution or work around. I suspect I know the solution, but that would be built on my assumptions about what code you are running. Best we avoid any confusion, frustration, or wasted time with any assumptions.

[Query-01]

@krzydoug – The code snippet I provided is the relevant code. Using that code, whether from the cli or placed in a ps1 will reproduce the issue. I provided the snippet as not to blow-up the screen with other code that does not affect the aforementioned snippet, or its resulting output, in any way.

[krzydoug]

This is the output of your code.

By default, powershell formats 4 or less properties as a table. 5 or more is displayed as a list

So please, share the code that is causing the issue you show in your screenshot so we can assist you.

[Query-01]

@krzydoug

This is the output of your code.

By default, powershell formats 4 or less properties as a table. 5 or more is displayed as a list

So please, share the code that is causing the issue you show in your screenshot so we can assist you.

@krzydoug – you have just reproduced the concern in your second image displayed as a list. Please do compare your second image with the image I provided. Notice the double line spacing between the Write-Output $_info cmdlet and its results, --that blank spacing is what I’m trying to remove.

[Olaf]

@Query-01

that blank spacing is what I’m trying to remove.

Just out of curiosity: Why?

Does it have a technical reason or is it just bothering you? If it’s the latter I’d recommend focussing on more rewarding tasks than spending a lot of effort to tinker around to remove one single emptly line from the output.

If you insist you could convert the output to a string an remove all empty lines from it before you output it.

Another option would be to use PowerShell 7.x. There Write-Output does not add an additional empty line to the output.

[krzydoug]

Have you tried just not using Write-Output? You don’t need it there at all.

[Query-01]

@Olaf

Another option would be to use PowerShell 7.x. There Write-Output does not add an additional empty line to the output.

Olaf – Thank you, that was part of my thinking which I have not found documented within the 5.1 help system for either Write-Output or Write-Host. I have only seen where other people are having issues with spacing and blank line’s but, not the same scenario as what I described.

I have seen a couple of other odd output or display issue’s, of which I temporarily resolved by either closing then reopening the host window or, switch to Powershell.exe. In this case, the output of the blank spacing, persist while using either the host\Terminal or Powershell.exe. All of this led to the belief, --it was most likely the cmdlet that processes the formatting.

The answer to your curiosity – the script I’m working on will use remoting to run quite a few cmdlet’s to pull data from numerous machine’s onto/into the console\file. The normal output formatting, with the exception of the blank lines, in this instance (the header), is fine. I could not figure out why every item in-fact displayed on screen as expected; except the Get-ComputerInfo first output, from the first machine, while the remaining output from the same cmdlet for all the subsequent machine’s was normal; as in not having the blank lines that are shown in the image attached to the initial post.

The usage of Out-file is not playing well with UNC path’s --for the non-local machine’s when I use Invoke-Command -ComputerName Pc1, Pc2, etc, etc -Scriptblock { ... }. In the mean time it seems easier to address the blank lines instead of, all the other speed-bump’s I’ve experienced with the output of this draft .ps1.

Before posting this concern I was sure to narrow down the issue to a certain something I was doing or using. That said, the reluctance to install PS 7.x is due to --all but one Win-10 box has their updates suspended indefinitely; citing overall OS stability. The current .Net install’s, on the boxes I have immediate physical access to:

PS C:\WINDOWS\system32> Invoke-Command -ComputerName Pc1, Pc2, Pc3 -Scriptblock { Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse | Get-ItemProperty -Name version -EA 0 | Where { $_.PSChildName -Match '^(?!S)\p{L}'} | Select PSChildName, version | format-table }

PSChildName                      Version
-----------                      -------
v2.0.50727                       2.0.50727.4927
v3.0                             3.0.30729.4926
Windows Communication Foundation 3.0.4506.4926
Windows Presentation Foundation  3.0.6920.4902
v3.5                             3.5.30729.4926
Client                           4.8.09032
Full                             4.8.09032
Client                           4.0.0.0



PSChildName Version
----------- -------
Client      4.8.09032
Full        4.8.09032
Client      4.0.0.0



PSChildName Version
----------- -------
Client      4.8.09037
Full        4.8.09037
Client      4.0.0.0

As you can see, no machine’s .Net install is compatible with PS 7.x and if I read correctly, only one version of PS 6.x is compatible with the .Net install on ‘one’ of these three machine’s. I’m not currently willing to sacrifice machine stability to upgrade Powershell to 7.x; the cost is too high. I’m not saying I’ll never upgrade, but not on these machine’s.

Also, do note the excessive blank line’s in the above output, the blank line’s are from running the pipe on only three machine’s. Obviously I’ll have to either look at your suggestion and learn how to convert all the .ps1 output using one or more of tostring(), Out-String -Stream and/or Select-String; I haven’t managed the time to focus on those (yet). I have other task’s that have me walking on hot coal.

Are there any suggestions I haven’t mentioned, on required reading to further address this concern while using PS 5.1?

[Olaf]

@Query-01

I’m not saying I’ll never upgrade, but not on these machine’s.

It wouldn’t be an upgrade since PowerShell 7 will install next to Windows PowerShell - not replacing it. A N D - if I got it right - you don’t need to update all machines - only the one you run the script from.

@Query-01

Also, do note the excessive blank line’s in the above output, the blank line’s are from running the pipe on only three machine’s.

So what? There are some additional blank lines. Why does it bother you? What do you do actually with the output? If you want to save it to a file for further process teps I’d expect you to use a structured format anyway … like CSV or XML or something like this.

It seems to me like you have what we call “The sharpened view on the insignificant detail.” It looks to me like you spend a lot of time and effort for actually no benefit at all.

[Query-01]

@Olaf

@Query-01

I’m not saying I’ll never upgrade, but not on these machine’s.

It wouldn’t be an upgrade since PowerShell 7 will install next to Windows PowerShell - not replacing it.

@Olaf … poor choice of wording; on my part. Because of the last year with two newly purchased Win-11 machine’s and the lack of OS stability --attributed to the auto-updating process, or something it installed, Stability was regained after postponing the 'Windows Update". I am not sure what role, if any, .Net update’s played.

@Olaf

A N D - if I got it right - you don’t need to update all machines - only the one you run the script from.

I remote from all three

@Query-01

Also, do note the excessive blank line’s in the above output, the blank line’s are from running the pipe on only three machine’s.

@Olaf

So what? There are some additional blank lines. Why does it bother you? What do you do actually with the output? If you want to save it to a file for further process teps I’d expect you to use a structured format anyway … like CSV or XML or something like this.

!XML, CSV = I use an older version of Excel, there would be a need to post-process the .ps1 output for formatting reasons.

@Olaf

It seems to me like you have what we call “The sharpened view on the insignificant detail.”

Sharpened view = ‘yes’, insignificant = “not to me”. that is your opinion, from your len’s; outside looking in.

@Olaf

It looks to me like you spend a lot of time and effort for actually no benefit at all.

Again, that is Olafs’ opinion from Olafs’ lens, it will benefit ‘me’, in at least two ways: i) learning how to do a thing, I learn better visually and with an active task; not some pre_formatted script or presentation. ii) Because I want the resulting output formatted 'my way, which was to use Out-File to a .txt. As I posted earlier " The usage of Out-file is not playing well with UNC path’s --for the non-local machine’s when I use Invoke-Command -ComputerName Pc1, Pc2, etc, etc -Scriptblock { ... }"

I am wanting the script.ps1 to output character’s I can manipulate within the script, without the need of post-processing. I’m sure there’s a way; I just haven’t discovered --what to read, to learn how to do it, without learning the process that involves Format-Custom; (yet).

[grey0ut]

@Query-01

This space has been confirmed as coming from Get-CompterInfo, which is generated regardless if run from a ps1 script or the cli:

I don’t have an answer for you here. Some cmdlets’ formatting has a blank line before and after output, but only visible on the console. It’s not capture in output.

$_info = Get-computerInfo "OsName", "OSDisplayVersion",  "OsVersion", "osinstalldate"
write-output $_info

Write-Output is implied if you simply call the variable like $_info so it is unnecessary.

You show us a picture of the output, but not the code that produces it. There is more than just the output of Get-ComputerInfo happening in this picture, but ultimately I think my response is going to be the same as my second sentence.

Invoke-Command -ComputerName Pc1, Pc2, Pc3 -Scriptblock { Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse | Get-ItemProperty -Name version -EA 0 | Where { $_.PSChildName -Match '^(?!S)\p{L}'} | Select PSChildName, version | format-table }

I know you’re mostly focused on console output in this discussion, but I would still advise against using Format-* cmdlets unless absolutely necessary as they convert your input objects in to something else in order to format them. That will limit you from being able to do much else with the output. In this code, you’re piping the output from each remote execution to Format-Table which is why you’re getting 3 distinct tables.
If instead you capture ALL of the output from your Invoke-Command in a variable, you could then pipe that to Format-Table if you like separately, but you don’t need to because as @krzydoug pointed out:

@krzydoug

By default, powershell formats 4 or less properties as a table. 5 or more is displayed as a list

Try running something like this instead:

$Results = Invoke-Command -ComputerName Pc1, Pc2, Pc3 -Scriptblock { Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP' -Recurse | Get-ItemProperty -Name version -EA 0 | Where { $_.PSChildName -Match '^(?!S)\p{L}'} | Select PSChildName, version }  
$Results

And now that you have a variable with your objects you can easily export them:

$Results | Export-Csv -Path C:\Temp\SomeStuff.csv -NoTypeInformation

I did a cursory search online for the appearance of blank lines in cmdlet output and I found some helpful information in this post:
SuperUser
But ultimately I would say, it’s built in to Powershell (and the formatters) and it might be easier to except the behavior.

[Query-01]

@grey0ut --Thank you, I see that I need to read these help files thoroughly and not skim through them. I do remember reading about how some cmdlet’s already include or, otherwise process their respective output’s as if the data was piped to Write-Host or Write-Output; I honestly forget which. I’m finding it challenging to remember that point while I’m actively adding to the script.ps1. Additionally, and admittedly, I haven’t paid much attention to how a Get-Cmdlet format’s its output, other than its an object. Again I see I need to read thoroughly.

The information which all of you, @krzydoug @Olaf and yourself have provided, is most helpful. If nothing else, it is confirming I have not yet lost what left of my mind; I just need to read and understand more of the help content.

Had I provided the .ps1 @krzydoug requested, I believed I would have blown-up the screen with unneeded content, as well as thinking --he would have done --what you did, i.e. fix then re-post the code. I would rather be directed to an article of a cmdlet or other method() to learn how; if that make’s any sense. The fact that @krzydoug was able to reproduce the concern with the snippet of code I provided, suggested he had all he needed to see exactly what I was experiencing; the extra blank line’s.

I’ll dig-in to your code along with the relevant help files, while comparing to my initial attempt, in an effort to see what I misunderstood, or just plain did not understand

[Edit] @grey0ut I already used your suggestion before adding Format-Table. The reason for using FT = the output uses less space.

[Query-01]

@krzydoug @Olaf @grey0ut – This image is closer to the intended goal. Does not take up a lot of space with empty line’s or space’s. I plan to include quite a few additional Get-cmdlet's within the .ps1, that will PS-remote to more than a few machine’s. I would like to keep the resulting output tight, without a lot of blank space between individual data (on the same line) or, between data-sets on a different line; like the image’s previously posted.

Continued Respect

[Olaf]

@Query-01

i) learning how to do a thing, I learn better visually and with an active task; not some pre_formatted script or presentation.

I am completely with you on that. No discussion.

@Query-01

ii) Because I want the resulting output formatted 'my way, which was to use Out-File to a .txt. As I posted earlier " The usage of Out-file is not playing well with UNC path’s --for the non-local machine’s when I use Invoke-Command -ComputerName Pc1, Pc2, etc, etc -Scriptblock { ... }"

I highly doubt that this way is the most effective or efficient one … even for having a quick overview over the returned results on the console. You may take a look at PowerShell 7.x and the cmdlet Out-ConsoleGridView.

@Query-01

!XML, CSV = I use an older version of Excel, there would be a need to post-process the .ps1 output for formatting reasons.

I highly recommend taking a look at the great module from Doug Finke ImportExcel. It does a lot of heavy lifting when you need to output to Excel. There is a Youtube video from the Research Triangle PowerShell User group with Doug talking about his module in detail and showing some really neat tricks.

@Query-01

I am wanting the script.ps1 to output character’s I can manipulate within the script, without the need of post-processing. I’m sure there’s a way; I just haven’t discovered

I know what you mean, but I don’t agree with your conclusion. I even would not use Get-ComputerInfo at all because it takes a lot of time and returns a lot of information I’m not after. Using individual Get-CimInstance cmdlets for the different values I need inside a single CIM session per remote machine will probably be even faster.

@Query-01

This image is closer to the intended goal.

Hmmm … of course this is a matter of personal taste but do you really think this output is clear and gives a good overview and is easy to digest or easy on the eyes? In case you wonder - I don’t.

[psdarwin]

One thing that caught my attention that you might be unaware of, which might help toward your goal. You were trying to run the command remotely and write the output from the remote computer to a file at a UNC path. To learn more about why this is difficult, read up on the double hop problem in PowerShell.

Because of that problem, it’s definitely easier to something like what @grey0ut suggested. Something like this:

$Results = Invoke-Command -ComputerName Pc1, Pc2, Pc3 -Scriptblock { <your commands here>}  
$Results | Export-Csv (or Out-File or however you want your results saved)

This brings all of the results back to the local machine, where they can be saved to a file without encountering the double hop problem.

And if the output is all put into $Results, the formatting will be consistent when you display it or write it to a file. You would do your formatting after you got all the data. That should take care of your extra line issue.

[Query-01]

[quote=“Olaf, post:14, topic:25296, full:true”]

@Query-01

@Query-01

ii) Because I want the resulting output formatted 'my way, which was to use Out-File to a .txt. As I posted earlier " The usage of Out-file is not playing well with UNC path’s --for the non-local machine’s when I use Invoke-Command -ComputerName Pc1, Pc2, etc, etc -Scriptblock { ... }"

I highly doubt that this way is the most effective or efficient one … even for having a quick overview over the returned results on the console. You may take a look at PowerShell 7.x and the cmdlet Out-ConsoleGridView.

@Olaf – I am interested in what PS 7 has to offer but, not at the potential risk and cost of these machines’ current stability.

@Olaf

@Query-01

!XML, CSV = I use an older version of Excel, there would be a need to post-process the .ps1 output for formatting reasons.

I highly recommend taking a look at the great module from Doug Finke ImportExcel. It does a lot of heavy lifting when you need to output to Excel. There is a Youtube video from the Research Triangle PowerShell User group with Doug talking about his module in detail and showing some really neat tricks.

This also sounds like a PS 7 thing.

@Olaf

@Query-01

I am wanting the script.ps1 to output character’s I can manipulate within the script, without the need of post-processing. I’m sure there’s a way; I just haven’t discovered

I know what you mean, but I don’t agree with your conclusion. I even would not use Get-ComputerInfo at all because it takes a lot of time and returns a lot of information I’m not after. Using individual Get-CimInstance cmdlets for the different values I need inside a single CIM session per remote machine will probably be even faster.

Remember the part about the infant description? I have seen but never used the CIM family. I’ve only ever (mostly) used GUI, sprinkled with some cmd.exe. My last experience with Fbsd has been more than a decade. It will take time to get back in the learning saddle; then I have to find the horse along with everything else.

I will take your guidance, as well as --start poking into everyone else’s suggestion’s. I’m still both surprised and embarrassed that I never found out about how to access the huge amount of data, in Windows, not necessarily with PS, --that the get-cmdlet’s both retrieve and output in one sweep, --without forcing you to view the data in a static format through a window. Engaging in a game of copy-n-paste to email’s and forum’s.

@Olaf

@Query-01

This image is closer to the intended goal.

Hmmm … of course this is a matter of personal taste but do you really find this output clear and easy to digest or easy on the eyes? In case you wonder - I don’t.

Olaf, for me, I’m quite happy that I’m close to understanding how I did it. This thread in-fact did help. As far as “clear and easy”, it may not be a pretty view, but for me, the “personal taste” you mentioned equates to: I can read it from left-right without excess space’s, the data sets are separated or grouped with a delimiter or horizontal-rule of my choosing. Basically it’s customized using what I’ll term as bare character’s, that I can manipulate within the .ps1; post-processing is not necessary but an option.

The original goal , forgive me for repeating, was to redirect all output to a non-delimited .txt. The PS 5.1 Get-cmdlet \\ServerName\ShareName\Folder | Out-File \\ServerName\ShareName\output.txt will not play nice inside of Invoke-Command -ComputerName Pc1, Pc2, Pc3 -Scriptblock { ... } --for all machine’s that are not local, claiming the drive or path does not exist. Until I can figure that out, I’ll settle for the last image I posted.

[Query-01]

@psdarwin

One thing that caught my attention that you might be unaware of, which might help toward your goal. You were trying to run the command remotely and write the output from the remote computer to a file at a UNC path. To learn more about why this is difficult, read up on the double hop problem in PowerShell.

Because of that problem, it’s definitely easier to something like what @grey0ut suggested. Something like this:

$Results = Invoke-Command -ComputerName Pc1, Pc2, Pc3 -Scriptblock { <your commands here>}  
$Results | Export-Csv (or Out-File or however you want your results saved)

This brings all of the results back to the local machine, where they can be saved to a file without encountering the double hop problem.

And if the output is all put into $Results, the formatting will be consistent when you display it or write it to a file. You would do your formatting after you got all the data. That should take care of your extra line issue.

@psdarwin – Before I read your post, I resolved the blank-line(s) and any excess spacing issues. While I’m sure there is a more concise and cleaner way, than what I created, the big win for me is, I understood enough to get it done. Moving forward, I’ll build on that and learn a cleaner way.

I actually had not yet returned to the attempts at trying to get Out-File to work inside of Invoke-Command -ComputerName Pc1, Pc2, Pc3 -Scriptblock { ... } , and ‘yes’, I was unaware of this “double hop problem in PowerShell” you speak of. Once I’m done fiddling with string, split, “array(s) -to- a var” --and calm down my typ-o’s, I will return to that suggestion:

$Results = Invoke-Command -ComputerName Pc1, Pc2, Pc3 -Scriptblock { <your commands here>}  
$Results | Export-Csv (or Out-File or however you want your results saved)

It will most likely be Out-File, thank you for the reminder and the “dble-hop” heads-up.

[grey0ut]

@Query-01

This also sounds like a PS 7 thing.

thankfully no, I use it in Windows Powershell v5.1 all the time.

[Query-01]

@Olaf @grey0ut This looks very promising, rewarding even.

[LearnLaughOps]

To answer your question bluntly - the extra blank line is the tableheader. You can hide the headers by piping your output to Format-Table -HideTableHeaders, but then it doesn’t display the data nicely. Since you’re just trying to display it in a friendly manner you can keep the $_info object as is. Then for displaying output just iterate through each property in the object and format it as you see fit.

$_info.PSObject.Properties | ForEach-Object {
    "$($_.Name) : $($_.Value)"
}