Fix broken header newlines and list-rule sanitisation

[cavejay]

• SanitisedFileFirstLine in the -MakeConfig default template used
  literal backtick-escape text (rn) instead of the {1} newline
  placeholder that eval-config-string actually expands, so the
  generated header printed as garbage on one line.
• List-type rules ("regex"="replacement","delimiter") never matched
  anything because of a typo ($matchesGroups instead of $matchGroups),
  an undefined variable that always evaluated to $null.

[cavejay]

Left inline notes on the three underlying bugs this PR fixes (header placeholder, list-rule typo, and the KeyList/console summary sorting-on-a-nonexistent-property + console-width-dependent formatting). All three were reproduced against the repo's own tests/ fixtures and against a larger 8000-line real-world logset (Linux/Apache/HDFS/OpenStack samples) before and after the fix — see the follow-up comment for a minimal repro any reviewer can run locally.

---

Generated by Claude Code

[cavejay]

Bug: eval-config-string only expands {0}/{1} placeholders (see its definition around line 431) — it does not interpret backtick escapes read back from a config file on disk. The old default template baked in literal `r`n text here instead of using the {1} newline placeholder the comment two lines above already documents, so every -MakeConfig run shipped a header that printed as one garbled line, e.g.:

This file was Sanitised at 09/10/2026 05:05:25.`r`n==`r`n`r`nAddress2

Switched to {1}, matching the pattern tests/sensitiveLists/list.conf already uses correctly (SanitisedFileFirstLine="...{1}{1}").

---

Generated by Claude Code

[cavejay]

Bug: $matchesGroups / $_matchesGroups are never assigned anywhere else in this file — the only populated variable is $matchGroups, set two lines above (line 951). So this block always read $null, meaning every list-type rule ("regex"="replacement","delimiter") silently matched nothing, no matter what it was pointed at.

Confirmed with tests/sensitiveLists/list.conf: before this fix, the comma/semicolon-separated fruit and building lists in simpleLists.log passed straight through unredacted. After the fix they get tokenised correctly (Fruit1,Fruit2,...).

---

Generated by Claude Code

[cavejay]

Bug: Sort-Object -Property name sorts on a property that doesn't exist on Dictionary.GetEnumerator() entries (they expose Key/Value, not Name), so it silently no-ops — and the result is piped into Out-String, whose default table formatting depends on console width. Outside an interactive terminal (headless run, Task Scheduler, redirected output — exactly the -Silent automation case the README documents), that width is invalid (-1) and Out-String renders nothing.

Net effect: KeyList.txt came out blank on every run I tested, even the small fixture files, even though the actual sanitisation was working correctly the whole time (the real key/value pairs were just never written out). Replaced with an explicit "Key - Value" line join so the output no longer depends on host formatting state. Same root cause fixed at line ~1680 below for the console "Processed Keys:" summary.

---

Generated by Claude Code

[cavejay]

Manual verification recipe

Two small self-contained checks — one for the header fix, one for the list-rule + KeyList fixes. I ran both against the base commit (0d3e0804) and against this branch's head to confirm the before/after below is real output, not a guess.

1. Header fix (-MakeConfig default template)

.\strippy.ps1 -MakeConfig
Select-String SanitisedFileFirstLine .\strippy.conf
.\strippy.ps1 .\your.log -o .\out -Silent
Get-Content .\out\your.sanitised.log -TotalCount 4

Before (base commit):

SanitisedFileFirstLine="This file was Sanitised at {0}.`r`n==`r`n`r`n"

This file was Sanitised at 09/10/2026 08:14:24.`r`n==`r`n`r`nConnection from Address1 refused
AllowedUsers: alice,bob,carol

The `r`n never expands — it lands in the file as literal text and the header eats the first content line with it.

After (this branch):

SanitisedFileFirstLine="This file was Sanitised at {0}.{1}=={1}{1}"

This file was Sanitised at 09/10/2026 08:14:29.
==

Connection from Address1 refused

2. List-rule + KeyList fixes

Save these two files next to strippy.ps1:

strippy-review.conf

[ Config ]
SanitisedFileFirstLine="This file was Sanitised at {0}.{1}=={1}{1}"

[ Rules ]
"((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]))[^\d]"="Address"
"AllowedUsers: (.+)$"="AllowedUser",","

review-test.log

Connection from 10.0.0.5 refused
AllowedUsers: alice,bob,carol

Run:

.\strippy.ps1 .\review-test.log -ConfigFile .\strippy-review.conf -o .\out -ko .\out\KeyList.txt -Silent
Get-Content .\out\review-test.sanitised.log
Get-Content .\out\KeyList.txt

Before (base commit):

Connection from Address1 refused
AllowedUsers: alice,bob,carol          <- list rule never fired, names left in plain text

--- KeyList.txt ---
(no keys listed — just the boilerplate header/filename lines)

After (this branch):

Connection from Address1 refused
AllowedUsers: AllowedUser3,AllowedUser1,AllowedUser2

--- KeyList.txt ---
Address1 - 10.0.0.5
AllowedUser1 - bob
AllowedUser2 - carol
AllowedUser3 - alice

One aside, not something this PR touches: on the base commit only, that same run occasionally logs a non-fatal Exception calling "Replace" with "2" argument(s): "The value cannot be an empty string." during Sanitising-Stripper, then still completes and produces the output above. Looks like a pre-existing, timing-dependent issue in the multi-threaded key-merge path, unrelated to the three bugs fixed here — flagging so it doesn't look like something this diff introduced if you see it while reproducing.

Also validated all four fixes together against the repo's own tests/ fixtures (no regressions) and against an 8000-line combined real-world logset (Linux/Apache/HDFS/OpenStack samples from loghub) exercising basic, list, and delete rule types — zero leftover sensitive values in the output, correct line deletion counts, and a fully populated KeyList.txt.

---

Generated by Claude Code