The first thing I'd suggest is that you not save the output of Format-List to a text file. The second is that without seeing the code you're using it's not possible to do more than guess at the reason for the differences.
Strange problem: I have a script that reads an object's ACL and saves it to a text file (Get-Acl objectname -Audit |FL > "textfile.txt"). Script has been working fine until I've bumped into the weird issue - occasionally the format of the resulting txt file is different from the one created previously (as I need to compare the old and the new files this leads to the false triggering), for example, if I run the script 6 times in a raw the format of the Sddl section will look as in the blue rectangle, but the 7th will look like in the red:
It does not matter whether there were any changes in ACLs or not - the format of SDDL strings can change without any (at least noticable) reason.
The two files do differ in formatting...
...but not in the content:
I've spent more than two days trying to pinpoint the situation in which those changes occur but to no avail, I just found out that the format may change any time in any way: it can change during the last 7 minutes or only the day after the script was run for the first time. The Sddl section may be made of 4-5-6 short strings, may be of 3-4 long ones. What can affect the way the PS formats a file???
Thank you in advance,
Sign in to comment
Sort by: Most helpful
"that you not save the output of Format-List to a text file" - sorry - did not understand it.
Here's the code: Get-Acl C:\test\Testfile.txt -Audit |FL > "c:\Temp\1.txt"
"That cmdlet is intended for displaying the object in a list format. It's output shouldn't be sent to a file." - no, this cmdlet (as any other format cmdlets) is intended just for arranging the data - not for displaying it:
**For example, this article says:*
The format cmdlets, such as Format-List, **arrange the data to be displayed but do not display it. **The data is displayed by the output features of PowerShell and by the cmdlets that contain the Out verb (the Out cmdlets), such as Out-Host or Out-File****.
If you do not use a format cmdlet, PowerShell applies that default format for each object that it displays.*
Having read the theory above why should one not use ...|FL > somefile ?
In any case, it's my understanding that it's not normal that the same procedure yields different results.
If you could post a link to such statement - It's output shouldn't be sent to a file - I'd very much appreciate it.
P.S. Here's the example of FL > file:
Input objects are automatically formatted as they would be in the terminal, but you can use a Format- cmdlet to explicitly control the formatting of the output to the file. For example, Get-Date | Format-List | Out-File out.txt*
Thank you all for your replies!
Whether that formatting is appropriate to your intended use is the issue. - I'd say the issue is this: "not "the list format is guaranteed to be the same all the time""
"Are the widths of the windows in which you're running #1 thru #6 different to the one in which you're running #7" - yes, they are. The problem arises when the new file has extra Carriage return/EOL... characters (or on contrary, does not have).
And I still don't understand why it should be better (theoretically):
"As Rich said, you will probably get better and more consistent results if you do this:"
Get-Acl C:\test\Testfile.txt -Audit | Select-Object -ExpandProperty Sddl | Out-File c:\Temp\1.txt
As MS says -
*The data is displayed **by the output features of PowerShell and by the cmdlets that contain the Out verb (the Out cmdlets), such as Out-Host or Out-File.*** - accrding to this any extra cmdlets (such as FL, FT) should not affect the way the file will look like - only PS itself + Out cmdlets must define the formatting.
I'll try to do more testing and post back the results.
If "(the "explicitly control the formatting" means "you get a list format", not "the list format is guaranteed to be the same all the time")" - if specifying the same set of parameters does not lead to the same output I would not call that process "explicitly control the formatting" :(