DEV Community: arnostorg

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.

Batch .bat in 2026: Legacy Glue, Not a Personality

arnostorg — Wed, 14 Oct 2026 13:28:09 +0000

I still write .bat files in 2026. I also refuse to build an identity around them. That distinction—legacy glue vs personality—is the retrospective I wish someone had handed me earlier.

Where `.bat` still appears (unironically)

Vendor installers and unwrap scripts.
Scheduled tasks authored a decade ago that still pay the bills.
Tiny wrappers that set env vars and launch something else.
Locked images where PowerShell scripts are political and CMD isn’t.

If your job touches Windows estates, you will read batch. Pretending otherwise is aesthetic, not operational.

What I no longer use batch for

Nontrivial logic (nested delayed expansion temples).
JSON / HTTP workflows.
Anything that needs testable functions and clear error objects.
Team-shared automation when PowerShell is available.

Writing clever batch to prove cleverness is a personality choice. Production doesn’t owe you applause.

Glue patterns that aged okay

Thin wrapper:

@echo off
setlocal
set APP_ENV=prod
"C:\Program Files\App\app.exe" %*
exit /b %ERRORLEVEL%

Explicit failure:

some-tool.exe || exit /b 1

Boring. Copyable. Reviewable.

Retrospective rules I keep

Prefer PowerShell (or a real language) for new automation when the environment allows.
Keep batch short when you must maintain it—delegate to something saner quickly.
Comment the why, especially quoting and setlocal choices.
Don’t teach batch as a first language for beginners beyond survival file ops and reading existing glue.

Teaching without contempt

Calling batch “ancient trash” shames juniors who just opened a vendor script. Calling it “beautiful” traps them in a cul-de-sac. Better: classify it as glue. You learn enough to untangle it, then you graduate.

Reading legacy batch without drowning

When you inherit a 400-line .bat:

Find the entry points and goto labels.
Note every setlocal / endlocal.
Track ERRORLEVEL after external calls.
Extract the “real work” (usually one .exe with flags).
Decide whether to wrap, rewrite, or quarantine.

Often the right 2026 move is a PowerShell rewrite plus a one-line .bat shim for callers that still expect a .bat path. Glue on the outside, sense on the inside.

Personality check

If you enjoy delayed-expansion puzzles more than shipping the installer’s outcome, notice that. Fascination is fine; production ownership is a different scoreboard.

Compatibility shim pattern

@echo off
pwsh -NoProfile -File "%~dp0tools\task.ps1" %*
exit /b %ERRORLEVEL%

Callers keep a .bat path; logic lives in something testable. That’s legacy glue with a 2026 brain—not a personality built out of goto.

When rewrite is the wrong first move

If a .bat is called from fifteen undocumented scheduled tasks, a clever rewrite without inventory is how you create an outage. Inventory callers, add logging, shim carefully, then rewrite the core. Legacy glue rewards patience more than contempt.

Documentation stub worth pasting above legacy scripts

REM Owner: platform-team
REM Purpose: thin launcher only — logic in tools\task.ps1
REM Last verified: 2026-09

Three lines prevent the next engineer from assuming the .bat is the product.

Glue is honorable when it’s thin, labeled, and temporary-by-intent—even if temporary lasts years.

That framing matches how I sequence Windows CLI practice in CMD Master: respect the artifact, don’t romanticize the dialect.

What I disabled in my own habits

Clever goto forests.
Environment mutation without setlocal.
Silent error ignoring.
Using batch where a checked-in PowerShell task would be clearer for the team.

.bat in 2026 is a compatibility surface. Use it like duct tape: proud when it holds, eager to replace it when you can engineer a joint.

PowerShell Out-File vs Set-Content: Encoding Is the Real Difference

arnostorg — Wed, 14 Oct 2026 07:26:52 +0000

Set-Content and Out-File both put text into a file. On a quiet English UTF-8 machine they look interchangeable. On a Czech log, a CSV opened in Excel, or a schedule that later runs under powershell.exe -File, they are not. The bug is almost never the path. It is the encoding you never asked for.

The shortest honest comparison

	`Out-File`	`Set-Content`
Default job	Capture pipeline output (what would print on screen)	Write string content into a file
Default encoding (Windows PowerShell 5.1)	Unicode (UTF-16 LE)	Default (often ANSI / system code page)
Default encoding (PowerShell 7+)	utf8NoBOM	utf8NoBOM
Overwrite vs append	`-Append` supported	Use `Add-Content` to append
Great at	Redirecting formatted cmdlet output	Writing known strings you control

If you memorize one row, memorize the 5.1 defaults. That is where most "my script worked on my laptop" tickets start.

Recipe 1: capture a command's screen output

Get-ChildItem C:\Logs -File |
    Sort-Object Length -Descending |
    Select-Object -First 20 |
    Out-File C:\Reports\top-logs.txt

Out-File is the file version of what you see. Objects still go through formatting first, so you get a readable table (or list), not a serialized object dump. That is exactly what you want for a human-readable report, and exactly what you do not want if the next step is another script parsing fields.

Need the same idea as > / >>?

Get-Service | Out-File C:\Reports\services.txt
Get-Process | Out-File C:\Reports\services.txt -Append

Recipe 2: write the text you mean

Set-Content -Path C:\Apps\config.env -Value @(
    'APP_ENV=prod'
    'LOG_LEVEL=info'
) -Encoding utf8

Set-Content replaces the whole file with the values you pass. No formatting layer. No surprise table headers. Pass an array and you get one line per element (plus a trailing newline, which is usually what you want).

Always name -Encoding when the file will leave your machine. Prefer:

Set-Content .\note.txt 'Příliš žluťoučký kůň' -Encoding utf8

On PowerShell 7, utf8 is fine. On Windows PowerShell 5.1, utf8 still writes a BOM. If a downstream tool hates BOMs, write bytes yourself or move the write to pwsh 7 with utf8NoBOM.

Recipe 3: the encoding trap in one demo

Run this on Windows PowerShell 5.1 and open both files in a hex editor or Notepad++:

'café' | Out-File .\via-outfile.txt
Set-Content .\via-setcontent.txt 'café'

Typical result on 5.1:

via-outfile.txt → UTF-16 LE (often starts with FF FE)
via-setcontent.txt → system ANSI (on Czech Windows, usually Windows-1250)

Neither is "wrong." Both are wrong if you assumed UTF-8. A later Get-Content without -Encoding, a Python script that opens as UTF-8, or Git treating the file as binary will all look like random corruption.

Force the contract:

'café' | Out-File .\via-outfile.txt -Encoding utf8
Set-Content .\via-setcontent.txt 'café' -Encoding utf8

Same string, same encoding, same future.

Recipe 4: when Out-File is the wrong tool

This pattern looks neat and silently loses structure:

# Fragile: formatting depends on console width and host
Get-ChildItem | Out-File .\files.txt
Get-Content .\files.txt | ForEach-Object { $_.Substring(0, 10) }  # will break

If another command must read the file, write data, not a screenshot of data:

Get-ChildItem -File |
    Select-Object Name, Length, LastWriteTime |
    Export-Csv .\files.csv -NoTypeInformation -Encoding utf8

Or, for simple line lists:

(Get-ChildItem -File).Name | Set-Content .\names.txt -Encoding utf8

Rule of thumb: Out-File for eyes, Set-Content / Export-Csv / ConvertTo-Json for machines.

Three traps worth knowing

Host width changes Out-File layout. Wide tables wrap differently when the window is narrow. A report that looked fine in an expanded console can become unreadable when a scheduled task runs with a default width. Fix with Out-File -Width 200 (or higher) when you care about columns.
> is Out-File with the same defaults. In Windows PowerShell 5.1, > creates UTF-16 files. Redirecting a UTF-8-looking string does not make a UTF-8 file. Prefer the cmdlet form with -Encoding whenever the file is shared.
Set-Content overwrites; it does not append. To add lines, use Add-Content (and still pass -Encoding so the first write and later appends agree). Mixing Out-File -Encoding utf8 with a later bare Add-Content is a classic way to glue two encodings into one "corrupted" log.

Pick one default and stick to it

For new scripts on mixed 5.1 / 7 fleets:

$utf8 = if ($PSVersionTable.PSVersion.Major -ge 7) { 'utf8NoBOM' } else { 'utf8' }
Set-Content .\app.log "started $(Get-Date -Format o)" -Encoding $utf8

Or standardize on PowerShell 7 for anything that writes text other tools will read. The command names stay the same. The encoding defaults finally stop fighting you.

Practice both without nuking a real config

Encoding bugs are ugly to debug on production shares. In CMD Master's interactive PowerShell lessons you can try Out-File, Set-Content, and -Encoding in a live browser terminal with instant feedback — no install, no VM. The same free Windows command line practice site also covers CMD and Bash when you hop between shells.

Your turn: have you been bitten by a UTF-16 Out-File landing in a UTF-8 pipeline? Drop the weirdest encoding mix-up you've hit in the comments.

I Built Interactive CLI Drills — Learners Quit at Prompt #3

arnostorg — Tue, 13 Oct 2026 13:45:33 +0000

I Built Interactive CLI Drills — Learners Quit at Prompt #3

I built what I wanted as a learner: interactive CLI drills in the browser. Type commands. Get feedback. No “install fifteen tools first.” Then the analytics (and the hallway conversations) said something rude: a chunk of learners quit at prompt #3.

This is a show-and-tell about that product bruise—and what I changed.

What I shipped first

Short missions for CMD, PowerShell, and Bash-oriented tasks on Windows-friendly paths.
Immediate correctness checks.
A clean terminal UI that feels like practice, not a MOOC video.

The thesis: skill is built at the prompt. Screenshots weren’t enough (I had already burned myself on that experiment).

Prompt #3: the cliff

Patterns in the drop-off:

Prompt #1 was a win (list files, print a string). Dopamine.
Prompt #2 introduced one new concept. Still okay.
Prompt #3 combined concepts—or required recovery from error—without a scaffold. Confidence cratered.

It wasn’t “students are lazy.” It was difficulty curve arrogance. I had optimized for correctness of the skill model, not for the emotional runway of a first session.

Product fixes that mattered

Smaller concept steps

One idea per prompt until the streak feels earned. Combine later in a “mission boss,” not at step three.

Intentional recovery prompts

Instead of only happy paths, add a safe failure that teaches ERRORLEVEL / $LASTEXITCODE early—after a success, not instead of one.

Shell labeling everywhere

Ambiguity across CMD vs PowerShell was silent quit fuel. Labels and prompts now scream which contract you’re in.

Softer first-session definition of done

A complete first session can be six tiny wins. Heroics can be session two.

What I’d still defend

Interactive > passive for CLI. The quit data didn’t kill the thesis; it killed my pacing ego.

Also: soft CTAs beat launch-speak. The product exists to train operators, not to win a landing-page award.

Where it lives

Instrumentation that changed my mind

I stopped celebrating completion rate alone. I started watching:

median time-to-first-success,
drop-off by prompt index,
repeat visits within 48 hours,
qualitative “I felt dumb” comments (painful, gold).

Prompt #3 was the cliff on the first curriculum graph. After re-pacing, the cliff moved later—and got shorter. That’s product work, not vibes.

What “showdev” means here

Not a launch. A build diary: interactive Windows CLI practice is the medium; curriculum pacing is the hard problem; soft CTA is intentional. If you’re building a trainer, steal the quit-index chart idea before you polish marketing copy.

Design smell: “clever” early combines

If prompt #3 needs two new ideas and perfect quoting and an error recovery, you didn’t write a drill—you wrote a hazing ritual. Split it. Clever can wait until the streak feels real.

What I almost did wrong next

I almost responded to quit data by adding badges and streaks—gamification as a bandage. Maybe later. First fix was honesty about pacing. If the third prompt is a cliff, glitter won’t pave it. Make the third prompt a fair win, then earn the harder combines.

The drills are free and browser-based: CMD Master—interactive terminal learning for CMD, PowerShell, and Bash. If you try it, watch where you want to bail. That spot is probably my next design ticket.

Open build question

For those who’ve built coding or ops trainers: do you gate progress strictly, or let learners skip and return? I’m still torn between “force the reps” and “don’t imprison adults.”

Show-and-tell, not victory lap: prompt #3 humbled the roadmap.

Aliases vs Functions in Your PowerShell Profile — Pick Deliberately

arnostorg — Mon, 12 Oct 2026 14:07:36 +0000

Your PowerShell profile is a sharp tool. It can make every session yours—or make every script you demo mysteriously unreproducible on a clean machine. The alias-vs-function choice is where that fork shows up.

Ninety days of pruning my profile taught me: most “clever” aliases should have been functions—or deleted.

What each one is for

Aliases

Short names for commands: gcb → Get-Clipboard (example pattern).
Fine for interactive sugar.
Weak at parameterization beyond what the target already offers.
Easy to shadow real commands if you’re careless.

Functions

Named blocks with parameters, validation, help.
Can wrap multi-step workflows.
Can be documented and tested.
Still profile-scoped if you define them only there—but they’re honest about complexity.

Retrospective: what I kept as aliases

Only high-frequency, low-surprise renames that mirror muscle memory across machines I control—and never names that collide with built-ins I might need when teaching.

If I hesitated about the name, it didn’t deserve alias status.

What became functions

Anything with a default path.
Anything that combined Set-Location + git status + branch name.
Anything that needed -WhatIf or explicit parameters.

Example shape:

function Enter-Repo {
  param(
    [Parameter(Mandatory)]
    [string]$Name
  )
  Set-Location (Join-Path $HOME "repos\$Name")
}

Readable. Greppable. Not er.

The reproducibility rule

If a blog post, teammate, or student needs your session tricks to follow along, your profile has leaked into the lesson. Prefer:

Project scripts and checked-in helpers for shared workflows.
Profile for personal ergonomics only.
Explicit calls in teaching: type the real cmdlet names.

I demo with a clean profile more often now. Slower fingers, clearer talk track.

Corporate angle (foreshadowing a longer debate)

Personal profiles on locked jump boxes can be a blessing or an audit headache. Deliberate choices—small surface, no secrets in profiles, no shadowing curl/Invoke-WebRequest confusion—age better than a 400-line fireworks file.

What I disabled

Aliases that shortened already-short cmdlets.
Prompt logic that called the network.
Anything that loaded heavy modules synchronously at startup.

Startup time is UX. So is predictability.

Profile load hygiene checklist

Time your startup occasionally (Measure-Command { pwsh -NoLogo -Command exit } vs with profile).
Keep secrets out; use a secret manager.
Prefer Remove-Alias mistakes fixed early over shipping collisions.
Split “interactive sugar” from “automation libraries”—libraries belong in modules you can import deliberately.

Teaching demo trick

Open two panes: left with your profile, right with -NoProfile. Run the same demo commands in both when recording. If they diverge, your lesson has a hidden dependency.

A simple decision tree

Need a new name only? → Alias (maybe).
Need parameters, defaults, or multiple steps? → Function.
Need teammates to run it? → Module or repo script, not your profile.
Need it in a screenshot lesson? → Use the real cmdlet names.

Tape that tree above your Microsoft.PowerShell_profile.ps1.

The “demo debt” metric

Every alias in your teaching profile is a potential demo debt item: something that works for you and fails for them. I keep a sticky note count of demo debt. When it rises above three, I strip the profile and re-record. Painful once; cheaper than confusing a cohort.

One alias I deleted and didn’t miss

I had a two-letter alias for Set-Location to a deep project path. It saved keystrokes and destroyed transfer: every teammate asked why cd “didn’t work like yours.” Deleting it slowed me for a day and clarified every demo after.

For learning environments, I want the opposite of mystery meat profiles: explicit prompts and skills you can practice cold. That’s the ethos I design toward in CMD Master.

Keep aliases tiny. Put logic in functions—or in repos. Pick deliberately.

PowerShell Sort-Object: Order Files by Size, Date, or Name in One Pipeline

arnostorg — Mon, 12 Oct 2026 07:30:04 +0000

A disk is filling up and you need to know which files are eating it. Or a log folder has 400 files and you want the newest one. Explorer can sort a column, but it can't sort by two things at once, it can't cut the list to the top 10, and it can't hand that list to the next command. Sort-Object can.

The one-liner that answers "what's taking all the space?"

Get-ChildItem -File | Sort-Object Length -Descending | Select-Object -First 10 Name, Length

What happens here:

Get-ChildItem -File sends file objects down the pipeline. -File skips folders, which matters (see the traps below).
Sort-Object Length sorts by the Length property, which is the size in bytes. It compares numbers, not text.
-Descending puts the biggest first. Without it you get the smallest first, which is rarely what you want at 2 a.m.
Select-Object -First 10 keeps the top ten and shows only the two columns you care about.

Swap Length for LastWriteTime or Name and the same line sorts by date or name. That's the whole idea: pick a property, pick a direction, cut the list.

Recipe 1: newest files first

Get-ChildItem C:\Logs -File | Sort-Object LastWriteTime -Descending | Select-Object -First 5

LastWriteTime is a real DateTime, so you get true chronological order. No guessing whether 01/02 means January or February.

Need just the single newest file to open it?

$latest = Get-ChildItem C:\Logs\*.log | Sort-Object LastWriteTime | Select-Object -Last 1
notepad $latest.FullName

Recipe 2: top 10 largest files on a whole tree, in MB

Get-ChildItem D:\Shares -File -Recurse -ErrorAction SilentlyContinue |
    Sort-Object Length -Descending |
    Select-Object -First 10 FullName, @{ Name = 'MB'; Expression = { [math]::Round($_.Length / 1MB, 1) } }

The @{ Name = ...; Expression = ... } part is a calculated property. It turns raw bytes into something a human can read without changing what you sorted on. -ErrorAction SilentlyContinue keeps "access denied" folders from flooding the screen.

On PowerShell 7 you can skip Select-Object -First and use Sort-Object Length -Top 10, which is shorter and avoids sorting the entire list in memory just to keep ten rows.

Recipe 3: sort by two properties at once

Get-ChildItem -File | Sort-Object Extension, Length

Files are grouped by extension first (.csv, then .log, then .zip), and inside each group they're ordered by size. This is the thing Explorer can't do.

Want the groups in A to Z order but the biggest file first inside each group? Use hashtables to set the direction per property:

Get-ChildItem -File | Sort-Object @{ Expression = 'Extension'; Descending = $false },
                                  @{ Expression = 'Length';    Descending = $true }

Recipe 4: keep the newest 5 backups, delete the rest

This is where sorting stops being cosmetic and starts doing ops work:

Get-ChildItem D:\Backups\*.bak |
    Sort-Object LastWriteTime -Descending |
    Select-Object -Skip 5 |
    Remove-Item -WhatIf

Sort newest first, skip the five you want to keep, delete everything else. -WhatIf prints what would be removed. Read that list carefully, then run the same line without -WhatIf. Drop this into a scheduled task and you have backup rotation in four lines.

Three traps worth knowing

Numbers stored as text sort like text. If you read values from a CSV or a file name, they're strings, and strings sort character by character:

   '9', '10', '100' | Sort-Object
   # 10, 100, 9

Cast inside a script block to sort them as numbers:

   '9', '10', '100' | Sort-Object { [int]$_ }
   # 9, 10, 100

The same thing bites with names like log1.txt, log10.txt, log2.txt. Pad numbers with zeros when you create files (log001.txt) and the problem never shows up.

Name sorting depends on culture. Sort-Object uses your current culture and ignores case by default. On a Czech system, ch is a separate letter that sorts after h, so chyba.txt lands after hosts.txt. If a script must produce the same order on every machine, say so explicitly with Sort-Object Name -Culture 'en-US' or add -CaseSensitive when case matters.
Name vs FullName on recursive listings. With -Recurse, Sort-Object Name mixes files from every folder into one alphabetical list, so two config.json files from different projects end up next to each other with no hint of where they live. Sort by FullName to keep each folder's files together, or by DirectoryName, Name to make that grouping explicit.

Bonus trap: folders have no Length property. If you forget -File, all the folders bunch up at one end of a size sort and look like zero-byte files.

Why the pipeline version beats clicking column headers

Explorer's column sort is fine for a glance. But it can't combine two sort keys, it can't stop at the top 10, it can't recurse a whole share into one list, and it can't pass the result on to Remove-Item, Copy-Item or Export-Csv. Sort-Object sits in the middle of a pipeline, so the answer to "which files?" becomes the input to "now do something with them". Once that clicks, you stop sorting to look and start sorting to act.

Practice it without touching real files

Recipe 4 deletes things, so it's worth getting the pipeline right somewhere safe first. In CMD Master's interactive PowerShell lessons you can practice Get-ChildItem, Sort-Object and the rest of the pipeline in a live browser terminal with instant feedback, no install and no VM. The same free command line learning platform also covers Windows CMD and Bash if you switch between systems.

Your turn: what do you sort by most often, size, date, or something weirder? Drop your favorite Sort-Object line in the comments.

The UTF-8 / Code Page Surprise That Corrupted My Log Parser

arnostorg — Sun, 11 Oct 2026 13:30:41 +0000

The UTF-8 / Code Page Surprise That Corrupted My Log Parser

The parser wasn’t wrong. The bytes were fine. My shell lied about what “text” meant—and I shipped a log tool that mangled non-ASCII lines until a Czech filename in a support zip made the bug undeniable.

This is a diagnostic post about Windows code pages, PowerShell encoding defaults, and why “just use UTF-8” is a process, not a slogan.

The failure symptom

A small PowerShell script:

Ran an external tool that emitted logs.
Captured output / read a .log file.
Parsed timestamps and paths with regex.
Wrote a summary CSV.

On my machine: green. On a colleague’s machine: paths with diacritics became ?? or mojibake, and the CSV “couldn’t find” files that Explorer showed clearly.

Classic encoding heisenbug: locale + shell + redirect + tool disagreed.

The moving parts (Windows edition)

System ANSI code page (legacy) still influences some apps and CMD behaviors.
OEM code page shows up in consoles historically (chcp).
PowerShell 5.1 vs PowerShell 7 differ in how often UTF-8 saves you by default.
Redirects and pipelines to native executables can re-encode.
File reads without -Encoding use defaults you didn’t consciously pick.

If you only test with ASCII, you never meet these parts.

The diagnostic sequence that found it

Look at raw bytes, not the rendered console string. A hex glance (or reading as byte array) showed UTF-8 sequences that the parser later interpreted as something else.
Check the console code page: chcp in CMD; in PowerShell, inspect [Console]::OutputEncoding and $OutputEncoding.
Check how the file was read/written: Get-Content / Set-Content / Out-File encoding parameters.
Ask which PowerShell edition ran in CI vs laptop.
Reproduce with a non-ASCII fixture checked into the repo (the missing test).

The smoking gun was a 5.1 path writing a file with a default that wasn’t UTF-8, then a later step reading it as UTF-8 (or vice versa). ASCII tests stayed green.

Fixes that are boring and correct

Pin encoding at every boundary: Get-Content -Encoding utf8, Export-Csv -Encoding utf8, etc. (know when utf8BOM matters for Excel-adjacent humans).
Prefer PowerShell 7 where allowed for friendlier defaults—but still pin.
For CMD-era tools, know chcp 65001 is a blunt instrument with side effects; don’t sprinkle it as superstition.
Add a CI fixture: Contrôle-Über-škoda.log or similar. If CI can’t round-trip it, you don’t ship.

Teaching takeaway

Encoding is not an advanced elective. It’s a diagnostic literacy topic that belongs next to PATH and exit codes—especially for Windows learners who live across CMD and PowerShell.

Minimal reproduction you can keep in a repo

Create a file with a non-ASCII name and UTF-8 contents.
Read/write it through your script on PowerShell 5.1 and 7.
Compare hashes / byte lengths.
Fail CI if they diverge from the expected encoding.

If that sounds heavy for a “small parser,” remember: the corruption only shows up for the customers you care about most—the ones whose languages don’t fit in seven-bit nostalgia.

Console rendering ≠ file encoding

Another trap: the console can display substitutions while the file on disk is fine (or the reverse). Always pin the layer you’re judging—screen, pipeline, or bytes on disk.

Empathy note for global teams

If your tooling assumes ASCII filenames, you’re quietly failing colleagues and customers whose names, cities, and documents don’t. Encoding literacy is inclusion work wearing debugging clothes.

I now treat “non-ASCII path survives the pipeline” as a required drill, not a niche. Interactive lessons in CMD Master are a natural place to force that fixture early, before someone corrupts a customer export.

If your parser only ever saw ASCII, you don’t have a parser. You have a happy path.

Why “Learn Linux First” Advice Hurts Windows-First Juniors

arnostorg — Sat, 10 Oct 2026 13:32:37 +0000

Why “Learn Linux First” Advice Hurts Windows-First Juniors

The advice is everywhere: if you want to be a real engineer, learn Linux first. Shell on Ubuntu. Dotfiles. Package managers that feel “clean.” Come back to Windows later, if you must.

For some careers, that path is fine. For Windows-first juniors—students on school-issued Windows laptops, IT helpdesk tracks, .NET shops, enterprise ops—the advice often delays competence and sneaks in shame.

The hidden curriculum in “Linux first”

It implies:

Windows shells are a side quest.
CMD/PowerShell knowledge is provisional.
Seriousness is measured by distro fluency.

Meanwhile their actual homework, internships, and first jobs keep handing them powershell.exe, Group Policy realities, and vendor .bat files. They’re told to practice somewhere else.

That’s not rigor. That’s misaligned reps.

What Windows-first learners actually need early

Paths, permissions, and process basics on the OS they own.
CMD survival skills for constrained machines.
PowerShell object pipelines (not Bash cosplay).
Encoding, Execution Policy, and PATH diagnostics they’ll hit in week two.
Permission to use Git Bash/WSL as tools, not as moral upgrades.

You can teach excellent operator habits on Windows. Transfer to Linux later is real—and easier when the person already understands exit codes, redirection, and “read the error.”

Where the advice comes from (charitably)

Many mentors lived Linux-heavy careers. Cloud images are Linux. Tooling docs assume Bash. None of that makes “abandon your daily driver” good pedagogy for a junior who only has a Windows laptop and four hours a week.

Charity doesn’t require copying their biography.

A better framing than culture war

Don’t replace “Linux first” with “Windows forever.” Replace it with platform-honest sequencing:

Gain fluency on the machine you can touch daily.
Learn concepts that transfer (pipelines, processes, files, networking basics).
Add Linux deliberately when your goals need it (cloud, containers, specific jobs).

Cross-training is strength. Displacement-as-identity is noise.

What I tell students now

If your world is Windows, practice Windows deeply. Use a browser-based or local lab that doesn’t pretend the shell is something else. When a README assumes Bash, translate consciously—or enter the Bash contract on purpose (Git Bash/WSL)—without calling it “real” and yourself “fake.”

Transfer that does work

Once someone can:

read errors calmly,
check exit codes,
reason about paths and permissions,
say which shell contract they’re in,

…then Linux practice accelerates. The transferable core is operator temperament plus fundamentals—not a specific distro badge.

Harm reduction if a mentor still pushes Linux-first

Negotiate a split: keep daily Windows practice; add a weekend Ubuntu VM or WSL track labeled as cross-training. Dual track beats abandonment. The injury happens when Windows practice stops entirely in the name of purity.

What I’m not claiming

I’m not claiming Linux skills are optional forever in cloud-heavy careers. I’m claiming sequencing and dignity matter. Windows-first juniors aren’t broken. Misaligned practice is.

Signal vs noise in mentor advice

Mentor advice often encodes the mentor’s job market year. Cloud-heavy 2018 advice isn’t automatically correct for a 2026 Windows helpdesk apprenticeship. Ask: “What OS will this student touch daily for the next ninety days?” Sequence to that. Add Linux as intentional breadth, not as an entrance exam to self-respect.

That’s the stance behind the Windows-friendly drills I work on in CMD Master: meet learners where their keyboards already are.

Discuss: Did “learn Linux first” help you, delay you, or both—and what does your first job actually run?

DEV Community: arnostorg

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

Invite for fellow instructors

Fourth almost-myth I nearly included

Closing challenge

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

The real costs (not the install one-liner)

When it was worth it for me

When it wasn’t

A pragmatic middle path

Retrospective verdict

My “worth it” segment budget

Rollback plan

Teaching tax, restated

Ninety-day keep/kill (prompt edition)

Font failure mode (so you’re not surprised)

Should Corporates Ban Personal PowerShell Profiles?

Should Corporates Ban Personal PowerShell Profiles?

The steelman for bans / lockdowns

The steelman for allowing constrained profiles

A third option: policy by tier

Norms that beat pure prohibition

What I’m asking the community

Failure stories I’ve heard (composites)

A question for security and platform teams

My personal vote (not a policy template)

Discuss framing for mixed audiences

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

Mental model: preview, then destroy

Recipe 1: dry-run with -WhatIf

Recipe 2: -Confirm when you want a human gate

Recipe 3: delete a folder tree carefully

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

A safe default ritual

Practice deletes somewhere that cannot hurt production

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

The seductive part

Where I got burned

Pipelines that “looked fine”

CI vs laptop gap

False green in batch wrappers

The tiny model that actually saves you

The i_tried rule I kept afterward

Product note

Two-week experiment protocol (replicable)

Teaching script you can steal

PowerShell-specific footgun

Incident postmortem one-liner

Pairing exercise (five minutes)

Batch .bat in 2026: Legacy Glue, Not a Personality

Where .bat still appears (unironically)

What I no longer use batch for

Glue patterns that aged okay

Retrospective rules I keep

Teaching without contempt

Reading legacy batch without drowning

Personality check

Compatibility shim pattern

When rewrite is the wrong first move

Documentation stub worth pasting above legacy scripts

What I disabled in my own habits

PowerShell Out-File vs Set-Content: Encoding Is the Real Difference

The shortest honest comparison

Recipe 1: capture a command's screen output

Recipe 2: write the text you mean

Recipe 3: the encoding trap in one demo

Recipe 4: when Out-File is the wrong tool

Three traps worth knowing

Pick one default and stick to it

Practice both without nuking a real config

I Built Interactive CLI Drills — Learners Quit at Prompt #3

I Built Interactive CLI Drills — Learners Quit at Prompt #3

What I shipped first

Where `.bat` still appears (unironically)