DEV Community: arnostorg

PowerShell Select-Object vs Format-Table: The Real Difference (and Why Your CSV Is Full of GUIDs)

arnostorg — Fri, 30 Oct 2026 08:24:18 +0000

Select-Object and Format-Table both let you pick which columns you see, and in the console they look almost identical. Then you pipe the result into Export-Csv and get a file full of GUIDs instead of file names. That is not a bug in Export-Csv. It is the one real difference between these two cmdlets, and once you see it you stop making the mistake.

Everything below was run in PowerShell 7.4.6. The behavior is the same in Windows PowerShell 5.1.

The shortest honest comparison

	`Select-Object`	`Format-Table`
What it outputs	Real objects with the properties you picked	Formatting instructions for the host
Can you sort, filter, or export afterwards?	Yes	No, not in any useful way
Where it belongs in a pipeline	Anywhere	Last, or right before `Out-File` / `Out-String`
Typical job	Shape data for the next command	Make data readable for a human

If you remember one rule, remember the one Microsoft Learn calls format right: formatting cmdlets go at the very end of the line.

The bug: Format-Table before Export-Csv

Here is the mistake almost everyone makes once:

Get-ChildItem C:\Logs\*.txt |
    Format-Table Name, Length |
    Export-Csv C:\Reports\logs.csv -NoTypeInformation

And here is what actually lands in the CSV:

"ClassId2e4f51ef21dd47e99d3c952918aff9cd","pageHeaderEntry","pageFooterEntry","autosizeInfo","shapeInfo","groupingEntry"
"033ecb2bc07a4d43b5ef94ed5a35d280",,,,"Microsoft.PowerShell.Commands.Internal.Format.TableHeaderInfo",
"9e210fe47d09416682b841769c78b8a3",,,,,
"27c87ef9bbda4f709f6b4002fa4af63c",,,,,

No file names, no sizes. The Export-Csv documentation warns about exactly this: Format-Table sends table format objects down the pipeline, and Export-Csv faithfully serializes those instead of your data.

The fix is one word:

Get-ChildItem C:\Logs\*.txt |
    Select-Object Name, Length |
    Export-Csv C:\Reports\logs.csv -NoTypeInformation

"Name","Length"
"log1.txt","101"
"log2.txt","201"
"log3.txt","301"

-NoTypeInformation is only needed in Windows PowerShell 5.1. PowerShell 7 leaves the #TYPE header out by default, and the switch is harmless there.

Prove it with Get-Member

You do not have to take anyone's word for it. Ask PowerShell what type comes out of each cmdlet:

Get-ChildItem *.txt | Format-Table Name, Length | Get-Member | Select-Object -First 1 -ExpandProperty TypeName
# Microsoft.PowerShell.Commands.Internal.Format.FormatStartData

Get-ChildItem *.txt | Select-Object Name, Length | Get-Member | Select-Object -First 1 -ExpandProperty TypeName
# Selected.System.IO.FileInfo

Select-Object gives you new objects that still carry Name and Length as real properties. Format-Table gives you internal formatting records that only the console knows how to draw.

The quieter bug: sorting and filtering after Format-Table

The CSV case is loud. These two are silent, which makes them worse.

# Looks fine, sorts nothing
Get-ChildItem *.txt | Format-Table Name, Length | Sort-Object Length -Descending

There is no error. The table prints in the original order, because Sort-Object is sorting formatting records that have no Length property.

(Get-ChildItem *.txt | Format-Table Name, Length | Where-Object Length -gt 200 | Measure-Object).Count
# 0

(Get-ChildItem *.txt | Select-Object Name, Length | Where-Object Length -gt 200 | Measure-Object).Count
# 4

Same input, same filter, completely different answer. If a script "finds nothing" and there is a Format-* anywhere before the filter, that is your first suspect.

The right order: filter, sort, select, then format

Get-ChildItem C:\Logs -File |
    Where-Object Length -gt 1MB |
    Sort-Object Length -Descending |
    Select-Object -First 10 Name, Length, LastWriteTime |
    Format-Table -AutoSize

Read it left to right: narrow the data, order it, keep the columns you need, and only then make it pretty. Swap the last line for Export-Csv, ConvertTo-Json, or another cmdlet and the pipeline still works, because everything before it is real data.

Calculated columns belong in Select-Object too

Both cmdlets accept calculated properties, so it is tempting to build a "SizeKB" column inside Format-Table. Build it in Select-Object instead and it survives the export:

Get-ChildItem C:\Logs\*.txt |
    Select-Object Name, @{Name = 'SizeKB'; Expression = { [math]::Round($_.Length / 1KB, 2) }} |
    Export-Csv C:\Reports\logs-kb.csv -NoTypeInformation

"Name","SizeKB"
"log1.txt","0.1"
"log2.txt","0.2"
"log3.txt","0.29"

When Format-Table is exactly right

Format-Table is not the villain. It is the right tool whenever a human is the last consumer:

# Readable console output
Get-Service | Where-Object Status -eq 'Running' | Format-Table Name, DisplayName -AutoSize

# Readable text report for a ticket or email
Get-ChildItem C:\Logs -File | Format-Table Name, Length -AutoSize | Out-File C:\Reports\logs.txt

Out-File and Out-String understand formatting records, so a formatted table written to a .txt file looks exactly like it did on screen. See the Format-Table reference for -AutoSize, -Wrap, and -GroupBy.

Two Select-Object switches worth knowing

From the Select-Object reference:

# Just the values, not objects with one property
Get-ChildItem C:\Logs\*.txt | Select-Object -ExpandProperty Name

# Top N after sorting
Get-ChildItem C:\Logs -File | Sort-Object Length -Descending | Select-Object -First 5 Name, Length

-ExpandProperty is the one to reach for when the next command wants plain strings, like a list of names to feed into Remove-Item or Copy-Item.

Quick checklist

Next step is a cmdlet, a file format, or another script: use Select-Object.
Next step is your eyes or a .txt report: use Format-Table, and put it last.
Export full of GUIDs, sort that does nothing, or filter that returns zero: look for a Format-* too early in the pipeline.
Need a computed column you can export: build it in Select-Object with a calculated property.

Practice the pipeline order hands-on

Reading about pipeline order is easy; getting it right under pressure takes reps. CMD Master's free interactive PowerShell, CMD, and Bash practice in your browser lets you run real commands in a browser terminal with no install, so you can drill filter-sort-select-format until it is automatic.

What is the strangest thing you have found in a CSV that went through Format-Table first?

Windows FINDSTR Command: Find an Error Code Across Every Log File

arnostorg — Wed, 28 Oct 2026 08:21:29 +0000

Something broke overnight, the app wrote forty log files, and all you have is an error code like ERR-504. You don't need PowerShell, an editor, or a log tool for the first pass. findstr ships with every Windows install since XP, works in a locked-down cmd.exe, and can tell you which files contain the code, which lines, and whether it's there at all in one command.

This post is the version I actually use: search a whole folder tree, get line numbers, list only file names, avoid the space-separated-words trap, and use the exit code in a batch script.

The one-liner

findstr /s /i /n /l /c:"ERR-504" C:\Logs\*.log

What each switch does:

/s searches the current folder and every subfolder.
/i ignores case, so err-504 and ERR-504 both match.
/n prints the line number in front of each hit.
/l treats the search text literally (no regex surprises).
/c:"..." searches for the exact string, spaces included.

Output looks like this, one hit per line, with path:line:text:

C:\Logs\api\2026-10-27.log:1184:2026-10-27 03:12:09 ERR-504 upstream timeout /orders
C:\Logs\api\2026-10-28.log:22:2026-10-28 00:01:44 ERR-504 upstream timeout /orders
C:\Logs\worker\queue.log:907:retry 3/3 failed with ERR-504

That's the whole first-pass triage: you know which service logged it, when, and where to open the file.

Trap #1: spaces mean OR

This is the mistake almost everyone makes once:

findstr "upstream timeout" C:\Logs\api\*.log

That does not search for the phrase upstream timeout. Without /c:, findstr splits the text on spaces and matches lines containing upstream or timeout. You get far more lines than you expected and you don't notice why.

Use /c: whenever the text has a space:

findstr /i /l /c:"upstream timeout" C:\Logs\api\*.log

And when you do want OR, the space behavior is actually handy:

findstr /i /n "ERR-504 ERR-502 ERR-503" C:\Logs\api\*.log

That's every gateway error in one pass.

Trap #2: be explicit about literal vs regex

findstr's regex support is small: ., *, ^, $, [class], [^class], [x-y], \< and \> for word boundaries. There's no +, no |, and no {3} quantifiers. A dot in your search text is a wildcard unless you're in literal mode.

So say what you mean:

:: literal: a dot is just a dot
findstr /s /l /c:"v2.4.1" *.log

:: regex: lines that START with a date like 2026-10-28
findstr /r /n "^2026-10-28" C:\Logs\api\*.log

Adding /l or /r every time costs two characters and removes a whole class of "why does this match?" bugs.

Just tell me which files: /m

When the folder has hundreds of logs, you usually want the list of affected files first, not every line:

findstr /s /i /m /l /c:"ERR-504" C:\Logs\*.log

C:\Logs\api\2026-10-27.log
C:\Logs\api\2026-10-28.log
C:\Logs\worker\queue.log

Count them by piping into find /c /v "", which counts every line it receives:

findstr /s /i /m /l /c:"ERR-504" C:\Logs\*.log | find /c /v ""

Save the hits to a file you can attach to a ticket:

findstr /s /i /n /l /c:"ERR-504" C:\Logs\*.log > C:\Temp\err-504-hits.txt

Hide the noise: /v

/v prints lines that don't match. Combine it with a pipe to strip out the chatter before you search:

type C:\Logs\api\2026-10-28.log | findstr /v /i "DEBUG TRACE" | findstr /i /n "ERR-"

The first findstr throws away DEBUG and TRACE lines, the second finds the errors in what's left. Note that /n now numbers lines in the filtered stream, not the original file, so use the earlier one-liner when you need real line numbers.

Search many codes from a file: /g:

If the on-call runbook lists a dozen error codes, put them in a text file, one per line:

ERR-502
ERR-503
ERR-504
DB-DEADLOCK

Then:

findstr /s /i /n /l /g:C:\Runbook\codes.txt C:\Logs\*.log

Updating the list is now an edit to codes.txt, not to the command.

Use the exit code in a script

findstr sets %ERRORLEVEL% to 0 when it finds at least one match and 1 when it finds none. That makes it a clean yes/no check in a batch file:

@echo off
findstr /s /i /m /l /c:"ERR-504" C:\Logs\*.log >nul
if %errorlevel%==0 (
    echo ERR-504 found. Check C:\Logs before closing the incident.
    exit /b 1
) else (
    echo No ERR-504 in the logs.
)

Or as a quick one-liner at the prompt:

findstr /s /i /m /l /c:"ERR-504" C:\Logs\*.log >nul && echo FOUND || echo clean

Trap #3: a file that "should" match returns nothing

findstr reads files as single-byte text. If a log was written as UTF-16 (for example with > redirection in Windows PowerShell 5.1, whose default output encoding is UTF-16 LE), every character has a null byte next to it and findstr typically finds nothing, with no error.

Quick check: open the file in Notepad and look at the encoding in the status bar. If it says UTF-16, either search it from PowerShell instead:

Select-String -Path C:\Logs\*.log -Pattern 'ERR-504' -SimpleMatch

or fix the writer so it outputs UTF-8. I wrote up the encoding side of this in PowerShell Out-File vs Set-Content: Encoding Is the Real Difference.

Cheat sheet

Goal	Command
Exact phrase, any case, whole tree, with line numbers	`findstr /s /i /n /l /c:"text" *.log`
Any of several words	`findstr /i "word1 word2 word3" *.log`
Only the file names	`findstr /s /i /m /l /c:"text" *.log`
Lines that do NOT match	`findstr /v /i "DEBUG" app.log`
Lines starting with a pattern	`findstr /r "^2026-10-28" app.log`
Many codes from a list	`findstr /s /i /l /g:codes.txt *.log`
Yes/no for a script	`findstr ... >nul`, then check `%errorlevel%` (0 = found)

Official reference: findstr on Microsoft Learn.

Practice it before the incident

Reading switches is easy. Remembering /c: at 3 AM is the hard part. If you want to build that muscle memory, CMD Master's free interactive Windows command line course runs a real terminal in your browser, with hands-on CMD, PowerShell, and Bash drills and instant feedback, so you can practice searching, filtering, and file operations without touching a production box.

What's the error code you grep for most often? Drop it in the comments.

PowerShell Get-ChildItem -Filter vs -Include: The Real Difference (and Why -Include Returns Nothing)

arnostorg — Mon, 26 Oct 2026 08:29:21 +0000

Get-ChildItem -Path C:\logs -Include *.log looks correct, runs without an error, and returns nothing. Swap -Include for -Filter and the files show up. Same cmdlet, same pattern, different result.

The two parameters run at different stages. -Filter goes to the provider, which skips non-matching files while it enumerates. -Include and -Exclude run inside PowerShell after the provider has already returned items, and only under certain path conditions. Once you know which stage you're working with, the "returns nothing" bug and the slow scripts both make sense.

Every command below was run in PowerShell 7.4.6 on Linux. I point out where Windows or Windows PowerShell 5.1 behaves differently, based on Microsoft's docs, because I couldn't test those here.

Build a small lab

Run this once. It creates a throwaway folder in your temp directory with a few tricky names: a folder whose name contains .log, an uppercase .LOG file, a .log.bak file, and the classic .htm / .html pair.

$root = Join-Path ([IO.Path]::GetTempPath()) 'gci-lab'
Remove-Item $root -Recurse -Force -ErrorAction SilentlyContinue
New-Item -ItemType Directory -Path "$root/logs/archive", "$root/logs/old.log.d" -Force | Out-Null
'a' | Set-Content "$root/logs/app.log"
'b' | Set-Content "$root/logs/web.log"
'c' | Set-Content "$root/logs/notes.txt"
'd' | Set-Content "$root/logs/error.LOG"
'e' | Set-Content "$root/logs/archive/2026-09.log"
'f' | Set-Content "$root/logs/archive/2026-09.log.bak"
'g' | Set-Content "$root/logs/report.html"
'h' | Set-Content "$root/logs/report.htm"
Set-Location $root

I pipe results to ForEach-Object Name to keep the output short. I don't use -Name because it changes how -Include behaves (more on that below).

The "returns nothing" gotcha

Get-ChildItem -Path ./logs -Filter *.log | ForEach-Object Name

app.log
error.LOG
web.log

@(Get-ChildItem -Path ./logs -Include *.log).Count

This isn't a bug, and it isn't only a Windows PowerShell 5.1 problem. It happened in pwsh 7.4. The Get-ChildItem docs say that -Include "is effective only when the command includes the contents of an item, such as C:\Windows\*". A plain -Path ./logs refers to the folder itself, not its contents, so nothing passes the include check.

You can fix it in any of three ways:

# 1. Wildcard path: "the contents of logs"
Get-ChildItem -Path ./logs/* -Include *.log | ForEach-Object Name

# 2. Add -Recurse (trailing * becomes optional)
Get-ChildItem -Path ./logs -Recurse -Include *.log | ForEach-Object Name

# 3. -LiteralPath (worked in pwsh 7.4 without * or -Recurse)
Get-ChildItem -LiteralPath ./logs -Include *.log | ForEach-Object Name

app.log
error.LOG
web.log

2026-09.log
app.log
error.LOG
web.log

app.log
error.LOG
web.log

The -Recurse version also goes into archive/. Keep that in mind if you add -Recurse only to make -Include work: you also get every subfolder.

The third fix is something I observed in pwsh 7.4, not documented behavior. On Windows PowerShell 5.1, use -Path ...\* or -Recurse. Those two are the forms the docs describe.

Bonus trap: `-Name` takes a different code path

"without -Name: " + @(Get-ChildItem -Path ./logs -Include *.log).Count
"with -Name:    " + @(Get-ChildItem -Path ./logs -Include *.log -Name).Count
"LiteralPath -Include *.txt -Name: " + @(Get-ChildItem -LiteralPath ./logs -Include *.txt -Name).Count

without -Name: 0
with -Name:    3
LiteralPath -Include *.txt -Name: 8

With -Name added, the "returns nothing" command returned 3 files. The -LiteralPath command that correctly returned only notes.txt returned all 8 items once -Name was added, so the include pattern was ignored. If you test an -Include command with -Name and then remove -Name in your script, you may get different results. Filter on objects first and select Name at the end.

What -Filter can and can't do

The docs describe it this way: the filter string is passed to the .NET file-enumeration API, it accepts one string, and only * and ? work as wildcards.

You can't pass more than one pattern:

Get-ChildItem -Path ./logs -Filter *.log, *.txt

Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'Filter'. Specified method is not supported.

Bracket ranges also don't work. You don't get an error, just no results:

@(Get-ChildItem -Path ./logs -Filter '[aw]*.log').Count
Get-ChildItem -Path ./logs/* -Include '[aw]*.log' | ForEach-Object Name

0
app.log
web.log

-Include uses PowerShell wildcards (about_Wildcards), so [aw] matches names starting with a or w. -Filter didn't treat [aw] as a character range and found nothing.

Also note that -Filter *.log returned error.LOG on Linux, where the file system is case-sensitive. I didn't expect that.

Windows-only quirks

On Windows, -Filter uses the operating system's file name matching rules, and the Directory.GetFiles docs list two old quirks:

Three-character extensions match longer extensions. On .NET Framework (the runtime under Windows PowerShell 5.1), *.xls also returns book.xlsx, so *.htm also returns .html. The docs label this ".NET Framework only". On .NET 5+ it returns only the exact extension. In my pwsh 7.4 lab, -Filter *.htm returned only report.htm.
8.3 short names are matched too. A pattern like *1*.txt can return longfilename.txt because its short name is LONGFI~1.TXT.

If a 5.1 script that uses -Filter *.htm deletes or moves files, run it on a test folder first. It may also catch .html files.

-Exclude: two behaviors that catch people

Unlike -Include, -Exclude works on a plain folder path:

Get-ChildItem -Path ./logs -Exclude *.log | ForEach-Object Name

archive
old.log.d
notes.txt
report.htm
report.html

But it only compares item names. It doesn't skip a subfolder during recursion:

Get-ChildItem -Path ./logs -Recurse -File -Exclude archive | ForEach-Object Name

2026-09.log
2026-09.log.bak
app.log
error.LOG
notes.txt
report.htm
report.html
web.log

The archive folder itself was excluded, but both files inside it were still returned. To skip a subfolder, filter on the path: Where-Object FullName -notlike '*/archive/*' (use \archive\ on Windows).

The second one: the docs say exclusions are applied after inclusions, and neither one cares whether an item is a file or a folder:

Get-ChildItem -Path ./logs -Recurse -Include *.log* -Exclude *.bak | Select-Object Mode, Name

Mode  Name
----  ----
----- 2026-09.log
d---- old.log.d
----- app.log
----- error.LOG
----- web.log

The folder old.log.d matches *.log*, so it's included. Adding -File removes it:

Get-ChildItem -Path ./logs -Recurse -File -Include *.log* -Exclude *.bak | ForEach-Object Name

2026-09.log
app.log
error.LOG
web.log

-File and -Directory are FileSystem-provider switches. Use one whenever your pattern could match both files and folders. -Filter has the same problem: -Filter *.log* -Recurse also returns old.log.d.

How much faster is -Filter?

The Measure-Command docs show -Filter being much faster on C:\Windows. Here is the same comparison on a generated tree with 20,000 files, so you can rerun it yourself:

$root = Join-Path ([IO.Path]::GetTempPath()) 'gci-perf'
Remove-Item $root -Recurse -Force -ErrorAction SilentlyContinue
$ext = '.log', '.txt', '.json', '.csv', '.tmp'
foreach ($d in 1..200) {
    $dir = New-Item -ItemType Directory -Path (Join-Path $root "app$d") -Force
    foreach ($f in 1..100) {
        [IO.File]::WriteAllText((Join-Path $dir "file$f$($ext[$f % 5])"), 'x')
    }
}
"Files created: " + (Get-ChildItem $root -Recurse -File).Count

# warm-up so the first run doesn't pay the cold cache cost
$null = Get-ChildItem $root -Recurse -File

$tests = [ordered]@{
    'Filter *.log'             = { Get-ChildItem -Path $root -Recurse -File -Filter *.log }
    'Include *.log'            = { Get-ChildItem -Path $root -Recurse -File -Include *.log }
    'Where-Object Extension'   = { Get-ChildItem -Path $root -Recurse -File | Where-Object Extension -eq '.log' }
    'Include *.log, *.csv'     = { Get-ChildItem -Path $root -Recurse -File -Include *.log, *.csv }
    'Filter twice (log + csv)' = { '*.log', '*.csv' | ForEach-Object { Get-ChildItem -Path $root -Recurse -File -Filter $_ } }
}

foreach ($name in $tests.Keys) {
    $runs = 1..5 | ForEach-Object { (Measure-Command $tests[$name]).TotalMilliseconds }
    [pscustomobject]@{
        Test     = $name
        Matches  = @(& $tests[$name]).Count
        MedianMs = [int]($runs | Sort-Object)[2]
    }
}

Files created: 20000

Test                     Matches MedianMs
----                     ------- --------
Filter *.log                4000       50
Include *.log               4000      428
Where-Object Extension      4000      219
Include *.log, *.csv        8000      487
Filter twice (log + csv)    8000       97

All runs were on the same 8-core Linux box with a warm cache, median of 5. Some results surprised me:

-Filter was about 8× faster than -Include for the same 4,000 files.
-Include was slower than Get-ChildItem | Where-Object. You might expect a built-in parameter to beat a pipeline filter. Here it took twice as long.
Running -Filter twice beat one -Include with two patterns (97 ms vs 487 ms), even though it walks the tree twice.

Expect different absolute numbers on Windows, network shares, and cold caches, but the ranking should be the same, because -Filter skips non-matching files before PowerShell creates objects for them.

The pattern I use now

One name pattern → -Filter, plus -File or -Directory:

Get-ChildItem -Path ./logs -Recurse -File -Filter *.log

Several patterns or [a-z] ranges → -Include with -Recurse or a \* path. When speed matters, narrow first with -Filter and refine with -Include. The two can be combined:

Get-ChildItem -Path ./logs -Recurse -File -Filter *.log -Include 'a*', 'w*' | ForEach-Object Name

app.log
web.log

Anything based on size, age, or path → Where-Object after a -Filter:

(Get-Item ./logs/app.log).LastWriteTime = (Get-Date).AddDays(-40)
Set-Content ./logs/web.log -Value ('x' * 2048)

$cutoff = (Get-Date).AddDays(-30)
Get-ChildItem -Path ./logs -Recurse -File -Filter *.log |
    Where-Object { $_.Length -gt 1KB -or $_.LastWriteTime -lt $cutoff } |
    Select-Object Name, Length, @{ n = 'AgeDays'; e = { ((Get-Date) - $_.LastWriteTime).Days } }

Name    Length AgeDays
----    ------ -------
app.log      2      40
web.log   2049       0

If you want to try these commands without setting up a lab folder, you can practice PowerShell file commands in a free browser terminal on CMD Master. It also covers CMD and Bash.

Quick reference

You want	Use	Watch out for
One pattern, fast	`-Filter *.log`	Single string, `` and `?` only; on 5.1, `.htm` also matches `.html`
Several patterns	`-Include .log, .csv`	Needs `-Recurse` or `path\*`, otherwise 0 results
Remove matches	`-Exclude *.bak`	Compares names only, still descends into excluded folders
Files only / folders only	`-File` / `-Directory`	`.log` also matches a folder named `old.log.d`
Size, date, path logic	`Where-Object { ... }` after the pipe	Narrow with `-Filter` first
Names only	`ForEach-Object Name` after the pipe	`-Name` changes how `-Include` behaves

Have you run into any of these, especially the -Name difference, on Windows PowerShell 5.1? I'd like to compare results.

PowerShell Compare-Object: Find Missing and Changed Files Between Two Folders

arnostorg — Fri, 23 Oct 2026 07:24:18 +0000

You copied a folder to a backup drive, a USB stick, or a new laptop. Now you need to know one thing: is the copy actually the same? Not "roughly the same size". The same files, with the same content.

Windows Explorer can't answer that. Compare-Object plus Get-FileHash can, in a short script you can rerun any time.

The one-liner: which file names differ?

Start cheap. Compare just the file names in two folders:

Compare-Object (Get-ChildItem C:\Photos -Name) (Get-ChildItem D:\Backup\Photos -Name)

InputObject        SideIndicator
-----------        -------------
IMG_2041.jpg       =>
IMG_1987.jpg       <=

Reading the SideIndicator column:

<= means the item exists only in the first (reference) set, here C:\Photos.
=> means it exists only in the second (difference) set, the backup.
Matching items are hidden. Add -IncludeEqual to see them marked ==.

So IMG_1987.jpg never made it to the backup, and IMG_2041.jpg is only on the backup.

That catches missing files. It does not catch a file that exists on both sides but has different content, like a half-copied video or a document you edited after the backup. For that you need hashes.

The real job: compare names and content, recursively

This script builds a fingerprint for every file (relative path plus SHA256 hash), then compares the two lists:

$left  = (Resolve-Path 'C:\Photos').Path
$right = (Resolve-Path 'D:\Backup\Photos').Path

function Get-FileFingerprint {
    param([string]$Root)
    Get-ChildItem -LiteralPath $Root -Recurse -File | ForEach-Object {
        [pscustomobject]@{
            RelPath = $_.FullName.Substring($Root.Length).TrimStart('\')
            Hash    = (Get-FileHash -LiteralPath $_.FullName -Algorithm SHA256).Hash
        }
    }
}

$a = @(Get-FileFingerprint -Root $left)
$b = @(Get-FileFingerprint -Root $right)

Compare-Object -ReferenceObject $a -DifferenceObject $b -Property RelPath, Hash |
    Sort-Object RelPath

Why each piece matters:

RelPath strips the root, so C:\Photos\2025\a.jpg and D:\Backup\Photos\2025\a.jpg both become 2025\a.jpg and can actually match.
-Property RelPath, Hash tells Compare-Object an item is only "equal" when both the path and the content hash match.
@(...) forces an array even when a folder is empty. More on that below.

Identical files produce no output. What's left is the interesting part:

RelPath                Hash          SideIndicator
-------                ----          -------------
2025\IMG_1987.jpg      7427D152...   <=
2025\trip.mp4          3BB2ABB6...   <=
2025\trip.mp4          73CB3858...   =>
IMG_2041.jpg           A4FB6214...   =>

Notice trip.mp4 shows up twice, once per side with different hashes. That's the signature of a file that exists in both places but changed.

Turn it into a readable report

Two rows per changed file is accurate but annoying. Group by path and label each case:

Compare-Object $a $b -Property RelPath, Hash |
    Group-Object -Property RelPath |
    ForEach-Object {
        $status = if ($_.Count -eq 2) { 'Changed' }
                  elseif ($_.Group[0].SideIndicator -eq '<=') { 'Missing in backup' }
                  else { 'Only in backup' }
        [pscustomobject]@{ Status = $status; File = $_.Name }
    } |
    Sort-Object Status, File

Status             File
------             ----
Changed            2025\trip.mp4
Missing in backup  2025\IMG_1987.jpg
Only in backup     IMG_2041.jpg

Need to send it to someone or keep a record? Pipe the same result to Export-Csv:

... | Export-Csv -Path .\backup-diff.csv -NoTypeInformation

An empty report means the two folders match, file for file and byte for byte.

Gotchas that bite on real folders

1. An empty folder throws a terminating error. If Get-ChildItem finds nothing, it returns $null, and Compare-Object refuses it:

Cannot bind argument to parameter 'ReferenceObject' because it is null.

Wrapping the call in @(...) gives you an empty array instead, and the comparison simply reports every file on the other side as missing. That's why the script above uses $a = @(...).

2. Comparison is case-insensitive by default. Report.docx and report.docx count as the same name, which matches how NTFS behaves. If you're comparing against a Linux share or a Git checkout where case matters, add -CaseSensitive.

3. Hashing big folders is slow, so filter first. Hashing reads every byte. For a 200 GB media folder, compare cheap properties first and only hash what's left:

function Get-QuickFingerprint {
    param([string]$Root)
    Get-ChildItem -LiteralPath $Root -Recurse -File |
        Select-Object @{ n = 'RelPath'; e = { $_.FullName.Substring($Root.Length).TrimStart('\') } }, Length
}

Compare-Object @(Get-QuickFingerprint $left) @(Get-QuickFingerprint $right) -Property RelPath, Length

A different Length proves a file changed. The same length doesn't prove it's identical, so run the hash version when you need certainty.

4. Don't compare timestamps to verify a copy. CreationTime resets when a file is copied, and not every copy tool or sync client preserves LastWriteTime, so a time-based diff can flag thousands of false "changes". Content hashes don't care how the file got there.

5. It's not a line-by-line text diff. Compare-Object (Get-Content a.txt) (Get-Content b.txt) tells you which lines exist on only one side. It won't give line numbers, and a line that merely moved won't be reported. For code, use git diff. For "did this config gain or lose a line?", it's perfect.

Quick reference

Goal	Command
Names only	`Compare-Object (gci A -Name) (gci B -Name)`
Show matches too	add `-IncludeEqual`
Compare on chosen properties	`-Property RelPath, Hash`
Case-sensitive names	add `-CaseSensitive`
Content check	`Get-FileHash -LiteralPath $file -Algorithm SHA256`
Save report	`\

Practice it before you need it

The time you most need this is right after a backup or migration, which is the worst time to learn the syntax. If you want to get the pipeline habit into your fingers first, practice PowerShell pipelines like Get-ChildItem and Compare-Object in a free browser terminal on CMD Master. No install, and nothing on your real disk gets touched.

Official docs

Compare-Object on Microsoft Learn: {% raw %}SideIndicator, -Property, -IncludeEqual, -CaseSensitive, and the $null terminating error
Get-FileHash on Microsoft Learn: hash algorithms and -LiteralPath
Get-ChildItem on Microsoft Learn: -Recurse, -File, and -Name
Group-Object on Microsoft Learn
Export-Csv on Microsoft Learn

Learning Windows command line from scratch? CMD Master's interactive CMD, PowerShell, and Bash lessons are free and run entirely in your browser.

Windows Robocopy Command: Mirror a Folder Without Deleting the Wrong Files

arnostorg — Wed, 21 Oct 2026 07:28:25 +0000

robocopy /MIR is the fastest way to keep two folders identical on Windows. It is also the fastest way to wipe a backup drive, because a mirror does more than copy. It deletes everything in the destination that isn't in the source.

This post covers the version I'd actually put in a scheduled task: preview it first, exclude what you don't want touched, stop the default retry loop from hanging for days, log every run, and read the exit code properly so 1 doesn't get flagged as a failure.

Copy vs mirror: /E vs /MIR

These two lines look nearly identical. They behave very differently.

robocopy C:\Projects D:\Backup\Projects /E
robocopy C:\Projects D:\Backup\Projects /MIR

/E copies all subfolders, including empty ones. Files that exist only in the destination are left alone.
/MIR is /E plus /PURGE. Files and folders that exist only in the destination are deleted.

So if you deleted old-notes.txt from C:\Projects last week, /E keeps the copy on D: and /MIR removes it. That's exactly what you want for a true mirror. It's exactly what you don't want if D:\Backup\Projects also holds files that were never in the source.

Rule of thumb: use /E when the destination is an archive and /MIR when it's a disposable replica.

Step 1: dry run with /L

/L lists what robocopy would do without copying, deleting or touching timestamps. Run it every time you build a new mirror command:

robocopy C:\Projects D:\Backup\Projects /MIR /L /NJH /FP /NDL

/L lists only. Nothing changes on disk.
/FP shows full paths so you can tell which side a file is on.
/NDL hides directory lines so the file actions stand out.
/NJH drops the job header.

Look for lines marked *EXTRA File. Those are the files /MIR will delete from the destination. If that list contains anything you care about, stop and fix the command before you remove /L.

You can try the flag-reading habit without risking a real disk in CMD Master, a free browser terminal for practicing Windows CMD, PowerShell and Bash. Nothing gets installed and nothing you break is real.

Step 2: exclude what the mirror must not touch

robocopy C:\Projects D:\Backup\Projects /MIR /XD node_modules .git bin obj /XF *.tmp ~$* Thumbs.db /L

/XD excludes directories by name or path.
/XF excludes files by name or wildcard.

Excluded items are skipped in both directions. They aren't copied from the source, and a matching folder that already exists in the destination isn't purged either. That makes /XD useful for protecting a folder in the destination that shouldn't be mirrored, like a local _archive folder.

If someone edits files directly on the destination, add /XO. It stops robocopy from overwriting a destination file with an older source copy:

robocopy C:\Projects D:\Backup\Projects /MIR /XO /L

This doesn't make two-way sync safe, because robocopy is still one-directional. It just stops the worst case of an old source copy overwriting newer work.

Step 3: fix the retry defaults

Robocopy's default retry settings are 1,000,000 retries with a 30 second wait between each one. A single locked file (an open Outlook PST, a database, someone's open Excel workbook) can stall a scheduled job for what is effectively forever.

Set retries explicitly:

robocopy C:\Projects D:\Backup\Projects /MIR /R:1 /W:1

One retry with a one-second wait is enough for a nightly job. The locked file gets reported as failed, and the next run picks it up.

Step 4: speed it up with /MT

robocopy C:\Projects \\nas01\backup\Projects /MIR /R:1 /W:1 /MT:16

/MT copies with multiple threads (default 8, range 1–128). It helps most with lots of small files over a network share. On a single spinning disk, high thread counts can make things slower, so test with 8 and 16 before going higher. Microsoft also recommends sending output to a log file when you use /MT, which brings us to logging.

Step 5: log every run

robocopy C:\Projects \\nas01\backup\Projects /MIR /R:1 /W:1 /MT:16 /LOG+:C:\Logs\projects-mirror.log /TEE /NP

/LOG+: appends to the log. /LOG: without the plus overwrites it every run, and your history goes with it.
/TEE writes to the console and the log at the same time, so interactive runs still show output.
/NP turns off the per-file percentage counter. Without it the log fills up with 10% 20% 30%... noise.

The summary block at the end of each run (Copied, Skipped, Mismatch, FAILED, Extras) is what you check when someone asks whether last night's backup worked.

Step 6: read the exit code correctly

This catches a lot of people. Robocopy's exit code is a bit field, not "0 = OK, anything else = error":

Code	Meaning
0	Nothing to copy. Source and destination already match.
1	Files were copied successfully.
2	Extra files exist in the destination. Nothing was copied.
3	Files copied and extras were found.
5, 6, 7	Combinations of copied, mismatched and extra files, with no failures.
8 and above	At least one file or folder failed to copy.

So %ERRORLEVEL% of 1 means success with work done. A script that does if errorlevel 1 goto :fail will report a failure every time the backup actually copies something. Task Scheduler does the same thing: "Last Run Result: 0x1" looks like an error but means files were copied.

Here's a batch wrapper that maps robocopy's codes to a normal 0 or 1 for whatever is calling it:

@echo off
setlocal

set "SRC=C:\Projects"
set "DST=\\nas01\backup\Projects"
set "LOG=C:\Logs\projects-mirror.log"

robocopy "%SRC%" "%DST%" /MIR /R:1 /W:1 /MT:16 /XD node_modules .git /XF *.tmp /LOG+:"%LOG%" /TEE /NP
set "RC=%ERRORLEVEL%"

if %RC% GEQ 8 (
    echo [%date% %time%] robocopy FAILED with code %RC% >> "%LOG%"
    exit /b 1
)

echo [%date% %time%] robocopy OK with code %RC% >> "%LOG%"
exit /b 0

Capture %ERRORLEVEL% into a variable right away. Any command after robocopy, including echo redirection, can change it before you check it.

Gotchas

Swapping source and destination. robocopy D:\Backup\Projects C:\Projects /MIR mirrors the backup onto your working folder and deletes everything you've created since the last backup. Worse, if the "source" path is an empty or freshly created folder, /MIR empties the destination. Put the paths in named variables like the script above, and always do a /L run when you change them.

A trailing backslash inside quotes. robocopy "C:\My Projects\" "D:\Backup\" breaks because \" is read as an escaped quote, so the arguments merge in strange ways. Drop the trailing backslash ("C:\My Projects"). If you need the root of a drive, leave it unquoted (D:\), since a drive root has no spaces.

Mirroring from a drive root. Copying from the root of a volume (for example E:\) can leave the destination folder with the Hidden and System attributes, so it seems to "disappear" in Explorer. Mirror a subfolder instead, or clear the attributes afterwards with attrib -h -s D:\Backup\E.

/MIR resets destination folder permissions. According to the docs, /MIR overwrites the destination directory's security settings, while /E /PURGE keeps them. If the destination share has carefully set ACLs, use /E /PURGE.

/MOV and /MOVE are not mirror options. They delete from the source after copying. Mixing them up with /MIR while "cleaning up" a command is a fast way to lose the original.

FAT/exFAT destinations recopy everything. USB drives formatted as FAT store timestamps with 2-second precision, so every file looks changed on every run. Add /FFT so robocopy allows for this.

A mirror command I'd actually schedule

robocopy "C:\Projects" "\\nas01\backup\Projects" /MIR /XO /R:1 /W:1 /MT:16 /XD node_modules .git bin obj /XF *.tmp ~$* /LOG+:"C:\Logs\projects-mirror.log" /TEE /NP

Run it with /L first, read the *EXTRA File lines, then remove /L, and wrap it in the exit-code script before it goes anywhere near Task Scheduler.

Official docs

Want to build flag-reading muscle memory before you run /MIR against a real share? Practice Windows CMD commands in CMD Master's interactive browser terminal. It's free, covers CMD, PowerShell and Bash, and has nothing to install.

From Tutorial Consumer to Operator: The Skills Gap CMD Master Targets

arnostorg — Mon, 19 Oct 2026 13:29:06 +0000

Watching CLI tutorials feels like progress. You nod at PATH diagrams. You pause a video to copy a command. You finish a playlist titled “Windows Command Line Full Course.” Then a production incident hands you a blank prompt and the playlist doesn’t play in your head.

That gap—tutorial consumer → operator—is the product problem I’m building around with CMD Master.

What tutorial consumption trains

Recognition of concepts when cued.
Happy-path sequences in the author’s order.
Confidence that is bound to narration.

What operators need

Initiation without a narrator.
State awareness (cwd, env, shell identity).
Recovery from errors under mild stress.
Transfer across CMD, PowerShell, and sometimes Bash contracts on one OS.

Those are different muscles. Screenshots and lectures can support them. They can’t replace them.

The skills gap in concrete behaviors

When someone is still a consumer, you see:

Panic on a non-zero exit they can’t name.
Paste of PowerShell into CMD (or the reverse) without noticing.
PATH “fixes” without verifying with where / Get-Command.
Avoidance of spaces/non-ASCII until reality forces a corruption bug.

When someone is becoming an operator, you see:

They inspect before they escalate.
They change one variable at a time.
They can explain which shell they’re in and why the quoting looks that way.
They write thin glue instead of mythic one-liners.

What CMD Master is (without launch-speak)

Curriculum pillars mapped to the gap

Consumer habit	Operator replacement drill
Watch PATH video	Break PATH on purpose; repair with verification
Copy pipe examples	Pipe objects; then pipe native text; name the difference
Read Execution Policy thread	Reproduce block; list scopes; narrow bypass
Finish playlist	Cold prompt: complete a six-step mission without narration

CMD Master’s job is to make the right column cheaper to practice than the left column is to binge.

What success looks like (non-vanity)

Not DAU cosplay. Success is: a Windows-first junior who can enter an unfamiliar shell, identify it, run a safe diagnostic, and recover from a non-zero exit without waiting for a YouTube reassuring voiceover.

Soft CTA philosophy (why one link)

This article is showdev with a point of view, not a landing page. One contextual link is enough; the work should make the next click optional rather than begged. Profile bio can carry the rest.

Build roadmap (honest, unfinished)

Better early pacing (post–prompt #3 scar).
More diagnostic missions (PATH, encoding, policy).
Clearer multi-shell labeling.
Covers and distribution experiments (this Dev.to Plan A queue).

Operators aren’t manufactured by a single article. They’re manufactured by repeated, honest practice under mild friction.

CMD Master is free interactive browser-terminal learning for CMD, PowerShell, and Bash, aimed at Windows-first learners. The design bet is simple: reps at a real prompt with feedback beat passive tours.

What we’re targeting in drills:

Early wins without lying about difficulty.
Explicit shell contracts.
Diagnostics (PATH, exit codes, quoting, encoding) as first-class—not appendices.
Soft boundaries so prompt #3 isn’t a cliff (learned the hard way).

What we refuse

Shame about CMD.
“Linux first or go home” gatekeeping.
Mega CTAs and hype posts pretending a trainer replaces a job.

Showdev status

This is still product work with fingerprints: quit points, myth-driven curriculum rewrites, comparison lessons for 5.1 vs 7 realities. If you teach Windows CLI, steal the sequencing ideas even if you never click the link.

The gap won’t close because someone watched one more video. It closes when the blank prompt stops feeling like a test they didn’t study for—and starts feeling like a tool they know how to pressure-test.

PowerShell Move-Item: Sort a Messy Downloads Folder by File Type in One Script

arnostorg — Mon, 19 Oct 2026 07:19:55 +0000

Every Downloads folder ends up the same way: 400 files, three of them named invoice (7).pdf, a dozen half-unzipped archives, and screenshots from a meeting nobody remembers. Dragging them into folders by hand takes twenty minutes. One Move-Item script does it in a second, and it can show you a full preview before it touches anything.

This post is that script, built up in small steps, plus the three Move-Item behaviours that bite people the first time they automate it.

The 10-second refresher

Move-Item (aliases move, mv, mi) moves a file or folder to a new location. If the destination is an existing folder, the item lands inside it with its name unchanged:

Move-Item -Path "$HOME\Downloads\report.pdf" -Destination "$HOME\Documents"

Two switches make it safe to automate:

Switch	What it does
`-WhatIf`	Prints what would move and moves nothing
`-PassThru`	Outputs the moved item at its new location, so you can log it

Full parameter list is in the official Move-Item documentation on Microsoft Learn.

Step 1: see what you are dealing with

Before sorting anything, group the files by extension so you know which folders you will get:

Get-ChildItem "$HOME\Downloads" -File |
    Group-Object Extension |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Typical output:

Count Name
----- ----
  142 .pdf
   61 .png
   38 .zip
   17 .xlsx
    9 .msi
    3

That last row with no name is files that have no extension at all. The script needs to handle those too.

Step 2: the sort script, in dry-run mode

$src    = "$HOME\Downloads"
$dryRun = $true   # flip to $false when the preview looks right

$files = Get-ChildItem -Path $src -File

foreach ($file in $files) {
    $ext = $file.Extension.TrimStart('.').ToLower()
    if (-not $ext) { $ext = 'no-extension' }

    $dest = Join-Path $src $ext

    if (-not (Test-Path -LiteralPath $dest)) {
        New-Item -ItemType Directory -Path $dest -WhatIf:$dryRun | Out-Null
    }

    Move-Item -LiteralPath $file.FullName -Destination $dest -WhatIf:$dryRun
}

Run it as is and you get one What if: line per file and nothing changes on disk. Read the list. When it looks right, set $dryRun = $false and run it again.

A few choices in there are deliberate:

$files = Get-ChildItem ... first, then loop. Collecting the list up front means the script works from a fixed snapshot instead of reading the folder while it is changing underneath it.
-WhatIf:$dryRun on New-Item too. If you only put -WhatIf on Move-Item, the dry run still creates a pile of empty pdf, png, zip folders. Passing the same switch to both keeps the preview truly side-effect free.
.ToLower(). Otherwise .PDF and .pdf would compete for the same folder name. Windows treats them as one folder, but the output looks messy and confusing.
-LiteralPath, not -Path. More on that in the gotchas below.

If you want the helpers explained in depth, I covered building folder paths with Join-Path and checking a path exists with Test-Path in earlier tips.

Step 3: do not lose `invoice.pdf` number two

Here is the first real-world failure. If pdf\invoice.pdf already exists and you move another invoice.pdf into the same folder, Move-Item stops with:

Move-Item: Cannot create a file when that file already exists.

-Force makes the error go away by overwriting the existing file, which is almost never what you want in a Downloads cleanup. Instead, pick a free name the way File Explorer does:

$target = Join-Path $dest $file.Name
$n = 1
while (Test-Path -LiteralPath $target) {
    $target = Join-Path $dest ('{0} ({1}){2}' -f $file.BaseName, $n, $file.Extension)
    $n++
}

Move-Item -LiteralPath $file.FullName -Destination $target -WhatIf:$dryRun

Swap that block in for the single Move-Item line from Step 2. Now the second invoice becomes invoice (1).pdf and nothing gets silently replaced.

Step 4: keep a log of what moved

When someone asks "where did my installer go?", you want an answer. -PassThru returns the item at its new location, so you can write it straight to a log file:

Move-Item -LiteralPath $file.FullName -Destination $target -PassThru |
    ForEach-Object { '{0}  {1}  ->  {2}' -f (Get-Date -Format s), $file.FullName, $_.FullName } |
    Add-Content -Path "$src\_moves.log"

Run this only after the dry run, because nothing is passed through while -WhatIf is on. The log gives you a timestamped line for every move, which is also everything you need to undo the cleanup by hand.

The three Move-Item gotchas

1. A missing destination folder turns your move into a rename.

# C:\Reports\Archive does NOT exist yet
Get-ChildItem C:\Reports -File | Move-Item -Destination C:\Reports\Archive

The first file is moved and renamed to a file called Archive with no extension. The second file then fails, because Archive now exists as a file. You end up with one mystery file and a screen of red errors. Always create the destination folder first, which is exactly why Step 2 runs Test-Path and New-Item before moving.

2. Square brackets in file names break -Path.

-Path treats [ and ] as wildcard characters, so this finds nothing:

Move-Item -Path "C:\Temp\report [final].pdf" -Destination C:\Archive

Downloads are full of names like photo [1].jpg. Use -LiteralPath whenever the name comes from real files rather than a pattern you typed. Piping Get-ChildItem output into Move-Item is safe as well, because the pipeline binds the exact path for you.

3. Moving folders to another drive depends on your PowerShell version.

Moving a file from C: to D: works everywhere. Moving a folder across drives in Windows PowerShell 5.1 fails with Source and destination path must have identical roots. Current PowerShell 7 releases handle it by copying and then deleting the source. On a locked work laptop stuck on 5.1, use Copy-Item -Recurse, check the copy, and only then remove the original (with a dry run first, as in the Remove-Item -WhatIf tip).

Bonus: move by age instead of type

The same pattern archives old files from a reports folder. This one moves anything not touched in 30 days:

$archive = 'C:\Reports\Archive'
$cutoff  = (Get-Date).AddDays(-30)

if (-not (Test-Path -LiteralPath $archive)) {
    New-Item -ItemType Directory -Path $archive | Out-Null
}

Get-ChildItem C:\Reports -File |
    Where-Object LastWriteTime -lt $cutoff |
    Move-Item -Destination $archive -WhatIf

Notice the folder gets created before the pipeline runs, so gotcha number one never gets a chance.

Practice the moves before you run them on real files

Typing these out on your actual Downloads folder for the first time is a bit nerve-wracking. In CMD Master's free interactive PowerShell lessons you can practise Move-Item, -WhatIf, and folder creation in a live browser terminal with instant feedback, with no install and nothing real to lose. The same hands-on Windows command line course covers CMD and Bash too, if you switch between shells at work.

Your turn: what does your Downloads folder look like right now? Run the Step 1 command and share your top extension in the comments. I am betting on .pdf.

Three Windows CLI Myths I Believed Until I Taught Them

arnostorg — Sun, 18 Oct 2026 13:25:41 +0000

Teaching is a myth detection machine. Ideas that feel true when you’re solo break when twenty learners follow them literally. Here are three Windows CLI myths I believed—and what replaced them after I tried teaching them out loud.

Myth 1: “CMD is obsolete; skip it.”

What I believed: PowerShell is the curriculum. CMD is history trivia.

What teaching revealed: Learners hit vendor .bat files, constrained images, and support scripts in the first month. Skipping CMD didn’t make them modern. It made them brittle.

Replacement: Teach CMD as a constrained toolkit for file ops and legacy glue, then graduate to PowerShell for structured automation. No shame lane.

Myth 2: “If they learn Bash on Linux/WSL first, Windows will be easy.”

What I believed: Transfer will Just Happen.

What teaching revealed: Quoting, path shapes, and pipeline semantics don’t transfer automatically. Learners who only practiced Bash treated PowerShell as broken Bash and blamed themselves.

Replacement: Platform-honest practice on the shell they’ll use this week. Add Git Bash/WSL as an explicit second contract—not as the “real” one. (Related rant energy, calmer delivery.)

Myth 3: “Tab completion + copy-paste is enough to become dangerous-in-a-good-way.”

What I believed: Ergonomics unlock competence.

What teaching revealed: Learners could assemble commands they couldn’t debug. Exit codes, encoding, and Execution Policy inspection were missing. They looked fluent until the first red error without a screenshot twin.

Replacement: Every module needs recovery reps. Completion is allowed; semantics are required.

How I “tried” these myths

Not in a lab coat—in cohorts and office hours. I taught the myth version, watched the failure mode, then changed the lesson. The bruise patterns repeated enough to retire the myths.

What I do differently in materials now

Name the shell on every example.
Put non-ASCII and spaces in paths on purpose.
Force where / Get-Command and exit code checks early.
Keep soft links to practice environments instead of launch-blog energy.

How the myths showed up in office hours

“I skipped CMD and now this vendor script is hieroglyphs.”
“I practiced on Ubuntu; PowerShell quoting feels random.”
“I tab-completed everything; why did CI fail with exit 1?”

Each sentence is a curriculum smell. If your materials produce those office-hour patterns, update the materials—don’t blame the learner’s grit.

Replacement myths I refuse to install

I also won’t install the reverse dogma (“never learn Linux,” “PowerShell is always wrong,” “GUIs are cheating”). Operator culture should be greedy for tools and precise about contracts.

Invite for fellow instructors

If you’ve retired a CLI myth after teaching it, keep a changelog. Curriculum honesty compounds. Myths hate changelogs.

Fourth almost-myth I nearly included

“Windows Terminal settings are the same thing as shell knowledge.” They’re not. Host configuration helps; it doesn’t teach exit codes. I cut it for length—but if you’re building a course, don’t let dockets of JSON themes replace fundamentals.

Closing challenge

Pick one myth you still teach “because everyone says it.” Teach the opposite for one cohort week—with measurement. Keep whichever version produces colder-prompt competence. Loyalty to slogans is optional; loyalty to outcomes isn’t.

If you want a place that assumes Windows-first operators deserve serious drills, I’m building that practice surface as CMD Master—free interactive browser-terminal learning for CMD, PowerShell, and Bash.

Myths feel efficient. Teaching makes them expensive. Pay the cost once in curriculum design, or pay it forever in office hours.

Oh My Posh Looks Cool. Here’s When It’s Worth the Setup Cost

arnostorg — Sat, 17 Oct 2026 13:28:53 +0000

Oh My Posh makes a Windows prompt look like a conference talk. Glyphs, segments, Git status, cloud context—eye candy with a purpose. I ran it, loved it, over-invested, then ripped most of it out. This retrospective is about when the setup cost is worth it.

The real costs (not the install one-liner)

Font dependency. Nerd Fonts (or equivalent) across terminals, VS Code, remote sessions. Miss one host and your prompt becomes mojibake theater.
Startup tax. Heavy segments that shell out to git/network on every prompt add friction on slow disks and large repos.
Cognitive load for demos. Students stare at your diamonds instead of your command.
Portability. Your brain expects segments that aren’t on locked corporate shells.

Install is easy. Habitat change isn’t.

When it was worth it for me

Daily driver machine I control end-to-end.
Work where repo/branch awareness prevents wrong-directory deploys.
A prompt theme with few segments (path + git + error) rather than a Christmas tree.
After the shell fundamentals were already boring and solid.

That last point matters. Prompt bling on top of confused exit codes is cosplay.

When it wasn’t

Teaching sessions (I switched to a plain prompt).
Jump boxes and customer machines.
CI-like terminals.
Any machine where installing fonts was a ticket.

Also: when I realized I was tuning theme JSON instead of finishing the task that made me open the terminal.

A pragmatic middle path

Use Oh My Posh (or a minimal PS prompt function) on personal/dev profiles only.
Keep a -NoProfile / plain profile muscle for teaching and support.
Cap segments ruthlessly. If a segment doesn’t prevent mistakes, it’s decoration.
Measure prompt time on your heaviest repo. If you feel it, cut it.

Retrospective verdict

Oh My Posh is worth the setup cost when it reduces wrong-context errors and you control the surface area. It’s not worth it as identity, as a teaching default, or as a substitute for learning the shell underneath.

My “worth it” segment budget

Allowed:

current path (shortened),
git branch + dirty state,
last command success/fail marker.

Denied (for me):

weather,
Kubernetes context on every prompt when I’m not on-call for it,
multiple cloud account glyphs,
clocks I can see on the taskbar.

Your budget may differ. The point is having a budget.

Rollback plan

Keep a prompt_plain profile (or -NoProfile habit) you can switch to in one click. If your bling can’t be disabled during an incident, it’s an operational liability.

Teaching tax, restated

Every glyph you add is something a learner might think is required knowledge. If it isn’t, hide it when you teach. Cool prompts are for machines you own; classrooms need the signal-to-noise ratio of a runway, not a festival.

Ninety-day keep/kill (prompt edition)

Kept: path + git + error marker on personal pwsh.

Killed: network segments, excessive glyphs, identical theme forced onto teaching demos.

Maybe later: a second theme for “focus mode” with path only.

The retrospective isn’t anti-beauty. It’s pro-mistake-reduction accounting.

Font failure mode (so you’re not surprised)

Remote desktop to a box without Nerd Fonts and your prompt becomes tofu boxes. If that box is a customer jump host, you just spent cognitive budget on cosmetics during an incident. Keep a plain profile reachable in one switch.

I’m biased toward plain prompts in learning products for that reason—see the deliberately un-fancy practice UX in CMD Master. Make the skill loud. Keep the chrome quiet until it earns a slot.

Cool is allowed. Cost accounting is required.

Should Corporates Ban Personal PowerShell Profiles?

arnostorg — Fri, 16 Oct 2026 13:23:56 +0000

Should Corporates Ban Personal PowerShell Profiles?

Personal PowerShell profiles are cozy. They also scare security teams: persistent custom code on jump boxes, shadowing built-ins, sneaky aliases that change what a runbook means, credentials that “temporarily” landed in a profile in 2019 and never left.

So—should corporates ban them? I don’t think the binary question is the useful one. The useful one is: what risk are you actually managing, and what operator freedom are you willing to trade?

The steelman for bans / lockdowns

Shared admin hosts shouldn’t depend on per-user surprise behavior.
Profiles can hide malware-ish persistence among legitimate UX.
Audit and change control get harder when every shell is unique.
Junior admins copy internet profiles that override curl, truncate history, or phone home for prompt themes.

If your environment is high-assurance and shared, “no arbitrary profile code” is a defensible default.

The steelman for allowing constrained profiles

Experts are faster with carefully chosen functions.
Absolute bans push work into shadow workarounds (USB scripts, personal laptops, unexplained binaries).
Teaching and onboarding sometimes need a controlled profile to demonstrate good patterns.
Not all hosts are equal: a developer laptop ≠ a tier-0 jump box.

A blanket ban across every Windows box treats unequal risk as equal.

A third option: policy by tier

Tier	Profile stance
Tier-0 / break-glass	Locked: signed profiles only or none
Shared ops jump boxes	Controlled: company-blessed profile repo
Developer endpoints	Allowed: guidance + secret scanning education
Training sandboxes	Encouraged: teach clean vs dirty profiles

This is more work than a meme policy. It’s also more aligned with how incidents actually happen.

Norms that beat pure prohibition

No secrets in profiles. Ever. Use secret stores.
Don’t shadow critical commands without extreme cause.
Prefer dot-sourced company modules over 500-line personal novels.
Demonstrate scripts with pwsh -NoProfile when reproducibility matters.
Code review the blessed profile the same way you review other tooling.

What I’m asking the community

Failure stories I’ve heard (composites)

An alias redefining a common command caused a runbook to skip a step on one admin’s laptop only.
A “temporary” credential in a profile synced via a dotfiles repo.
A prompt theme calling network APIs slowed every shell on a restricted VLAN until it looked like an outage.

None of these require assuming malice. They require assuming profiles are code.

A question for security and platform teams

If you ban profiles but don’t provide a blessed, reviewed module of shared helpers, you’re not removing customization—you’re pushing it underground. Pair controls with an official path for ergonomics.

My personal vote (not a policy template)

Ban or lock on tier-0.
Curate on shared ops hosts.
Guide and educate on developer laptops.
Always provide a blessed alternative for common ergonomics.

If you only ban, you outsource UX to shadow IT. If you only allow, you outsource risk to hope.

Discuss framing for mixed audiences

Security folks hear “ban.” Developers hear “trust me.” Platform folks hear “tiered control plane.” If your org can only have one conversation, have the tiered one—it forces everyone to name which machines they’re actually talking about.

I’m not selling a product feature here so much as an ops culture question—though I’ll admit clean-shell teaching is part of why I care about profile hygiene when building lessons for CMD Master.

Discuss: In your org, are personal PowerShell profiles banned, ignored, or curated—and which failure mode have you actually seen: malware persistence, runbook confusion, or death-by-tooling-rigidity?

PowerShell Remove-Item: Dry-Run Deletes with -WhatIf Before You Nuke Folders

arnostorg — Fri, 16 Oct 2026 07:24:16 +0000

You are about to wipe a folder on a locked work laptop. Recycle Bin is policy-disabled. There is no "oops, restore from backup" button for the next ten minutes. Remove-Item will do exactly what you typed — including the path you thought you typed. The only free safety net is a dry run.

Mental model: preview, then destroy

Remove-Item (aliases: rm, del, ri) deletes files and folders. Two common parameters change how sure you are before anything is gone:

Switch	What it does	When to use it
`-WhatIf`	Prints what would be deleted. Touches nothing.	Always before a recursive or wildcard delete
`-Confirm`	Asks Yes/No/All for each target (or a batch prompt)	Interactive cleanup when you want a human gate
`-Recurse`	Walks into folders	Folder trees — and the place most people regret speed
`-Force`	Overrides read-only / hidden / some prompts	Only after `-WhatIf` looked correct

On Windows PowerShell 5.1 and PowerShell 7 the switches work the same for this workflow. The difference that matters is you, not the version: dry-run first, then remove the safety switch.

Recipe 1: dry-run with -WhatIf

Remove-Item C:\Logs\*.tmp -WhatIf

You get lines like What if: Performing the operation "Remove File" on target "C:\Logs\old.tmp". Read every path. If one of them is C:\Logs itself or a sibling you did not mean, stop. Fix the pattern. Run -WhatIf again until the list is boring and correct.

Wildcard preview for a whole tree of junk:

Get-ChildItem C:\Temp\BuildCache -Recurse -File |
    Where-Object { $_.Extension -in '.tmp','.log','.bak' } |
    Remove-Item -WhatIf

Piping into Remove-Item -WhatIf still only simulates. Nothing is deleted until you drop -WhatIf.

Recipe 2: -Confirm when you want a human gate

Remove-Item C:\Staging\* -Confirm

PowerShell prompts before each item (or offers Yes to All). Use this when the set is small and you are watching the screen. Do not rely on -Confirm inside a scheduled task or a script that runs unattended — there is nobody to answer, and depending on host settings the call can hang or fail.

For scripts, prefer the -WhatIf review in a terminal, then a second run without it. For interactive one-offs at a desk, -Confirm is fine.

Combine both when you are nervous:

Remove-Item C:\Staging\export-2026-10-15 -Recurse -Confirm -WhatIf

-WhatIf wins: you still get a preview and no delete. Drop -WhatIf when the preview is approved; keep -Confirm if you still want click-through safety.

Recipe 3: delete a folder tree carefully

A non-empty folder refuses a bare Remove-Item without -Recurse:

# Fails if C:\Logs\OldRuns still has files
Remove-Item C:\Logs\OldRuns

The careful pattern:

# 1) Preview the tree
Get-ChildItem C:\Logs\OldRuns -Recurse | Select-Object FullName

# 2) Dry-run the delete
Remove-Item C:\Logs\OldRuns -Recurse -WhatIf

# 3) Only then
Remove-Item C:\Logs\OldRuns -Recurse

On locked corporate images, deleted items often skip the Recycle Bin entirely when removed from PowerShell. Treat step 2 as mandatory, not optional theater.

PowerShell 7 tip: same switches. If you delete large trees often, preview with Get-ChildItem first so you see count and depth before Remove-Item walks them again.

Recipe 4: the footgun — wrong path, wildcards, and -Force

These are the tickets that start with "I only meant to clear temp files."

Wrong path / too-broad wildcard

# Looks local. If you are in C:\ and mistype, you can match far more than you think.
Remove-Item .\* -Recurse -Force -WhatIf

Always prefer an absolute path for destructive work:

Remove-Item C:\Apps\MyService\cache\* -Recurse -WhatIf

-Force hides warnings

-Force clears the read-only bit and pushes through some confirmation paths. It does not make a bad path safe. Combining -Recurse -Force without a prior -WhatIf is how a typo in C:\Logs becomes C:\Log or worse.

Hidden / system files

Get-ChildItem C:\Logs -Force -Recurse |
    Where-Object { $_.Name -like '*.tmp' } |
    Remove-Item -WhatIf

Use -Force on Get-ChildItem to see hidden targets in the preview. Use -Force on Remove-Item only after that list looks right.

Providers other than the filesystem

Remove-Item also works on registry keys, certificates, and other providers. A path that starts with HKLM:\ or Cert:\ is not a folder on disk. If your muscle memory is filesystem-only, pause when the provider prefix is not C:\ / \\server\share.

A safe default ritual

Write the command with a full path.
Append -WhatIf.
Read the preview like a change ticket.
Re-run the same line without -WhatIf (add -Confirm if you still want prompts).
Keep -Force off until a read-only/hidden block is a known, reviewed exception.

That ritual is slower than a one-liner. It is also how you keep your job and the team's night quiet.

Practice deletes somewhere that cannot hurt production

The scary part of Remove-Item is that real machines forgive typos slowly. In CMD Master's interactive PowerShell lessons you can run Remove-Item, -WhatIf, and -Confirm in a live browser terminal with instant feedback — no install, no VM, no Recycle Bin policy surprises. The same free Windows command line practice site covers CMD and Bash when you hop between shells.

Your turn: what is the worst almost-delete -WhatIf ever saved you from? Drop the story (sanitized paths welcome) in the comments.

Tab Completion Won’t Save You From Not Understanding Exit Codes

arnostorg — Thu, 15 Oct 2026 13:38:01 +0000

I tried an experiment on myself: lean hard on tab completion and IntelliSense-ish shell helpers for two weeks, and deliberately not study exit codes beyond vibes. I wanted to see how far ergonomics carry you.

Far enough to look productive. Not far enough to be safe.

The seductive part

Tab completion reduces spelling errors. It surfaces parameters. It makes PowerShell feel modern. Students love it. I love it. This post is not anti-completion.

It’s anti-substituting UX for semantics.

Where I got burned

Pipelines that “looked fine”

A native tool failed halfway. The screen still printed something. Because I didn’t check $LASTEXITCODE / %ERRORLEVEL%, a later step ran on partial output. Tab completion had helped me type the broken pipeline faster.

CI vs laptop gap

Locally, aliases and profile helpers padded mistakes. In CI, bare shells told the truth. Completion wasn’t available in the same way; exit codes suddenly mattered and I had no muscle memory.

False green in batch wrappers

A .bat called a tool, ignored failure, exited 0 by accident of flow. The wrapper “completed.” Completion never enters that story. Semantics do.

The tiny model that actually saves you

Processes signal outcome with an exit code. By convention, 0 means success; non-zero means failure (with program-specific meanings).

PowerShell complications worth learning early:

$LASTEXITCODE for native executables.
-not $? / $true $false patterns for shell-level success.
Cmdlet errors vs native exit codes—different channels.

CMD:

mytool.exe
echo %ERRORLEVEL%

PowerShell:

mytool.exe
$LASTEXITCODE

Put that reflex before you chase prettier prompts.

The i_tried rule I kept afterward

For every new tool, I practice one happy run and one forced failure, then read the code. Tab-complete the flags. Still read the code.

When teaching, I now introduce completion as a speed tool after a first intentional failure exercise. Otherwise learners optimize for “command accepted by the completer,” not “operation succeeded.”

Product note

Two-week experiment protocol (replicable)

Week A: completion on, exit-code checks off (honor system).
Week B: completion still on, but every native call followed by an explicit status check in a learning log.

My log’s Week A was full of “looked fine.” Week B caught three silent partial failures I’d have pasted into a ticket as “weird output.”

Teaching script you can steal

Run a command that succeeds; show 0.
Run a command that fails; show non-zero.
Chain with && / || (CMD) or PowerShell equivalents carefully.
Only then celebrate tab completion as speed—not as truth.

PowerShell-specific footgun

Cmdlet errors and native exit codes aren’t the same channel. A pipeline can look chatty while $LASTEXITCODE still says the native tool failed. Completion won’t narrate that. Your checklist must.

Incident postmortem one-liner

“The command looked correct and the completer accepted it” is not a root cause. “We didn’t check the exit code before the next step” often is. Write that on a card. Completion stays; accountability stays harder.

Pairing exercise (five minutes)

Driver types a failing command on purpose. Navigator must state the exit code before suggesting a fix. No googling until the code is spoken aloud. It feels pedantic. It builds the reflex completion can’t.

Speed without a status check is just faster fiction.

Interactive drills are perfect for this: hide the next step behind a checked exit code. That’s a pattern I use while refining CMD Master—completion optional, outcome mandatory.

Ergonomics help you type. Exit codes tell you whether you should have.

DEV Community: arnostorg

PowerShell Select-Object vs Format-Table: The Real Difference (and Why Your CSV Is Full of GUIDs)

The shortest honest comparison

The bug: Format-Table before Export-Csv

Prove it with Get-Member

The quieter bug: sorting and filtering after Format-Table

The right order: filter, sort, select, then format

Calculated columns belong in Select-Object too

When Format-Table is exactly right

Two Select-Object switches worth knowing

Quick checklist

Practice the pipeline order hands-on

Windows FINDSTR Command: Find an Error Code Across Every Log File

The one-liner

Trap #1: spaces mean OR

Trap #2: be explicit about literal vs regex

Just tell me which files: /m

Hide the noise: /v

Search many codes from a file: /g:

Use the exit code in a script

Trap #3: a file that "should" match returns nothing

Cheat sheet

Practice it before the incident

PowerShell Get-ChildItem -Filter vs -Include: The Real Difference (and Why -Include Returns Nothing)

Build a small lab

The "returns nothing" gotcha

Bonus trap: -Name takes a different code path

What -Filter can and can't do

Windows-only quirks

-Exclude: two behaviors that catch people

How much faster is -Filter?

The pattern I use now

Quick reference

PowerShell Compare-Object: Find Missing and Changed Files Between Two Folders

The one-liner: which file names differ?

The real job: compare names and content, recursively

Turn it into a readable report

Gotchas that bite on real folders

Quick reference

Practice it before you need it

Official docs

Windows Robocopy Command: Mirror a Folder Without Deleting the Wrong Files

Copy vs mirror: /E vs /MIR

Step 1: dry run with /L

Step 2: exclude what the mirror must not touch

Step 3: fix the retry defaults

Step 4: speed it up with /MT

Step 5: log every run

Step 6: read the exit code correctly

Gotchas

A mirror command I'd actually schedule

Official docs

From Tutorial Consumer to Operator: The Skills Gap CMD Master Targets

What tutorial consumption trains

What operators need

The skills gap in concrete behaviors

What CMD Master is (without launch-speak)

Curriculum pillars mapped to the gap

What success looks like (non-vanity)

Soft CTA philosophy (why one link)

Build roadmap (honest, unfinished)

What we refuse

Showdev status

PowerShell Move-Item: Sort a Messy Downloads Folder by File Type in One Script

The 10-second refresher

Step 1: see what you are dealing with

Step 2: the sort script, in dry-run mode

Step 3: do not lose invoice.pdf number two

Step 4: keep a log of what moved

The three Move-Item gotchas

Bonus: move by age instead of type

Practice the moves before you run them on real files

Three Windows CLI Myths I Believed Until I Taught Them

Myth 1: “CMD is obsolete; skip it.”

Myth 2: “If they learn Bash on Linux/WSL first, Windows will be easy.”

Myth 3: “Tab completion + copy-paste is enough to become dangerous-in-a-good-way.”

How I “tried” these myths

What I do differently in materials now

How the myths showed up in office hours

Replacement myths I refuse to install

Bonus trap: `-Name` takes a different code path

Step 3: do not lose `invoice.pdf` number two