DEV Community: EL E

A Command That Matched Zero Files Still Exits 0: How to Catch Silent CI Failures

EL E — Mon, 05 Oct 2026 10:25:15 +0000

A Command That Matched Zero Files Still Exits 0: How to Catch Silent CI Failures

Every engineer has felt the cold dread of pushing a critical fix, watching the CI pipeline turn gloriously green, and then discovering in production that the deployment script didn't touch a single file because a glob pattern quietly evaluated to nothing.

The pipeline passed. The logs looked clean. But your code was never updated.

Why does this happen? In standard shell scripting and CI environments like GitHub Actions, commands like grep, find, or custom glob expansions frequently exit with status 0 even when they match zero files or process zero items. To a build system, "no errors encountered while running the binary" is indistinguishable from "successfully processed your target files."

In this article, we examine why silent zero-match failures are a silent killer of CI reliability, and how you can bulletproof your automation pipelines using strict assertion wrappers and open-source verification tools.

The Root of the Problem: Exit Code Ambiguity

Let's look at a typical cleanup or linting step in a CI pipeline:

find src/ -name "*.legacy.js" -delete

If src/ contains no files matching *.legacy.js, what does find return?
It exits with 0.

To the shell, find executed successfully: it searched the directory, encountered no permission errors or syntax issues, and completed its execution. It has no concept of your intent that matching files ought to exist.

Now scale this to a deployment workflow:

sed -i 's/OLD_VERSION/NEW_VERSION/g' dist/**/*.bundle.js

If your build step changed the output directory structure or filename extensions, dist/**/*.bundle.js might expand to a literal string or match nothing. sed might fail or do nothing, but depending on how the shell handles globbing (especially with nullglob disabled), the command might either fail or silently succeed with zero modifications. If your CI script uses set -e, it only catches non-zero exit codes. A zero exit code gives your pipeline a false sense of security.

Real-World Scenarios Where Zero-Match Slips Through

1. File Migration and Refactoring Scripts

During large-scale refactors, paths move around. If a CI maintenance script relies on relative paths to clean up temporary artifacts or migrate configuration files, a broken path changes the target from "all configuration files" to "nothing at all."

2. Security Audits and Secret Scanning

Imagine running a custom pre-commit hook or CI check to ensure no hardcoded private keys or tokens slipped into staging directories:

grep -rnw 'configs/' -e 'BEGIN PRIVATE KEY'

If configs/ was accidentally excluded or renamed in a recent PR, grep finds nothing and exits with 1 (no match found). But what if you wrappered or piped it incorrectly, or if the directory path was subtly wrong? In many complex pipeline scripts, exit codes from greps are swallowed by pipes or conditional wrappers (|| true), turning an intended security gate into a ghost barrier.

How to Fix It: Defensive Shell Scripting

To stop silent zero-match failures, you must enforce strict assertions on file operations before and after execution.

Approach 1: Pre-Check File Counts

Before running a batch operation, assert that your file list or glob expansion actually contains items:

#!/usr/bin/env bash
set -euo pipefail

files=( src/**/*.ts )
if [ ${#files[@]} -eq 0 ] || [ ! -e "${files[0]}" ]; then
  echo "Error: Expected TypeScript files to process, but found zero matches." >&2
  exit 1
fi

echo "Processing ${#files[@]} files..."
# Proceed with processing

Approach 2: Using Dedicated Verification Tools

For robust production pipelines, writing custom bash guards for every glob pattern becomes tedious and error-prone. This is why teams adopt specialized verification wrappers like zero-match-guard or offchain-integrity-verifier.

For instance, using zero-match-guard in your CI workflow ensures that any file operation or glob expansion explicitly fails the build if the match count falls below an expected threshold:

- name: Verify Migration Targets
  uses: elwakeupman-shhh/zero-match-guard@v1
  with:
    path: "dist/**/*.bundle.js"
    min-matches: 1

If zero files match the pattern, the action halts immediately with a clear diagnostic message, preventing broken artifacts from reaching downstream deployment stages. Similarly, for validating build integrity without heavy external dependencies, lightweight verifiers like offchain-integrity-verifier verify checksums and file presence locally in a single zero-dependency pass.

Conclusion

Silent CI failures are insidious because they rob you of visibility when things go wrong. By recognizing that exit code 0 only means "no command execution error" rather than "operation successfully acted on your expected targets," you can write significantly more resilient automation scripts.

Take a look at your CI pipelines today: are your file-processing steps protected against zero-match silent passes? Add explicit count checks or integrate guard actions like zero-match-guard to ensure your builds never lie to you.

Your ops dashboard does not need a frontend framework

EL E — Mon, 05 Oct 2026 01:47:01 +0000

The dashboard I actually look at every morning is one HTML file with a <script> tag
and no build step. It polls three JSON files on disk and renders a table. It has been
running unattended for weeks.

I want to argue for that shape, because the default reflex — spin up a framework,
a bundler, a component library, a dev server — costs more than it returns for this
specific category of page.

What an internal dashboard actually is

Strip away the ceremony and an ops dashboard is:

Read some state that another process already wrote down.
Show it.
Do it again in fifteen seconds.

There is no routing. There is usually one viewer. There is no SEO, no SSR, no
hydration, no design system. The interaction budget is "click a link, maybe sort a
column".

<script>
async function tick() {
  const [status, targets, alerts] = await Promise.all(
    ["status.json", "targets.json", "alerts.json"].map(f =>
      fetch(f + "?t=" + Date.now()).then(r => r.json())));
  render(status, targets, alerts);
}
tick();
setInterval(tick, 15000);
</script>

That is the whole architecture. The hard parts of this page were never rendering.

The hard parts are elsewhere

Freshness. A dashboard that silently shows yesterday's numbers is worse than a
blank page, because a blank page makes you go and check. Mine prints the generation
timestamp of every source file next to the data, and marks anything older than its
expected interval. The number is never shown without saying when it was true.

Saying "unknown" instead of zero. If a source file fails to parse, the honest
render is unknown, not 0. I learned this the expensive way: a JSON file written
by a different tool carried a byte-order mark, json.load raised, the exception was
swallowed, and the page rendered a beautifully empty table. It looked fine. It was
just empty. (The fix was encoding="utf-8-sig". The lesson was that the failure had a
display mode indistinguishable from success.)

Counting what you did not check. Any panel that says "all green" has to also say
how many things it examined. "12/12 checks passed" and "0 checks found" are wildly
different states that render identically if you only show a colour.

None of those three are frontend problems. A framework helps with none of them.

What you give up

Honestly: components, hot reload, type checking across the template boundary, and the
ability to hand the page to someone who only writes React.

For a page with four panels and one reader, I have not missed any of them. At around
a dozen panels with real interaction I would reconsider — but I would reconsider by
adding one small library, not by starting a project.

The part that actually matters

Whatever you build it with, the dashboard's job is to be trusted. That means:

every number carries its timestamp,
a source that could not be read says so instead of rendering zero,
and any "passed" claim states its denominator.

A page that gets those three right in plain HTML is more useful than a beautiful one
that quietly shows stale data — because the first one you can act on, and the second
one you will eventually act on when it is wrong.

I build these: single-page operational dashboards, health checks, and the collectors
behind them. No framework, no build step, no monthly service — one file you own and
can read end to end. Available for hire on Fiverr.

One command, one file: script in, 1080p episode and a vertical short out

EL E — Sun, 27 Sep 2026 03:44:40 +0000

I run a small storytelling channel. Every episode needs the same five things done in the
same order: clean the script, generate narration, render a 1080p video, cut a vertical
short, and verify the output is what I think it is.

For a while I did that with a folder of half-remembered ffmpeg incantations. Then I
wrote it down as one script. Now an episode is a single command:

python make_episode.py ep05_minxiong.md ep05_minxiong

Here is the actual output from the last run:

[1/5] cleaned script: 2096 chars
[2/5] narration: ep05_minxiong_narration.mp3  2,658,384 bytes  443.1s
[3/5] long video:  ep05_minxiong_long_1080p.mp4  6,871,754 bytes / 443.1s
[4/5] short cut:   ep05_minxiong_short_vertical.mp4  892,786 bytes / 58.0s
[5/5] evidence (ffprobe measured, not filename-inferred)

Nothing exotic is happening. The interesting part is what I stopped doing.

Step 5 is the whole point

The last line of that output says "ffprobe measured, not filename-inferred". That exists
because of a bug that cost me several planning cycles.

Two files in my working directory were called ep02_..._long_1080p.mp4 and
ep03_..._long_1080p.mp4. For weeks they appeared in my schedule as full episodes. They
were 80.7 and 78.9 seconds. Nobody had ever measured them. The word long in the
filename had been doing the job that a measurement should have been doing.

So the pipeline now ends by running ffprobe on everything it produced and printing the
real duration and byte count:

def evidence(path):
    out = subprocess.run(
        ["ffprobe", "-v", "error", "-show_entries", "format=duration",
         "-of", "default=noprint_wrappers=1:nokey=1", path],
        capture_output=True, text=True, check=True).stdout.strip()
    return float(out), os.path.getsize(path)

It is four lines. It is also the only part of the script that has ever caught a real
problem. A pipeline that does not measure its own output is not a pipeline, it is a
hope.

The dependency question

The whole thing is standard library plus two external binaries: ffmpeg and a
text-to-speech CLI. No framework, no orchestration layer, no config format I have to
remember the schema of six months from now.

That is a deliberate trade. I give up a plugin system I would never have written plugins
for, and in exchange the script still runs on a machine I have not touched since I wrote
it. There is no lockfile to resolve, no transitive dependency that went unmaintained, no
virtualenv that quietly rotted.

For a tool that runs on a schedule and that nobody is watching, "still runs a year later"
beats "elegant" by a wide margin.

Why a short is generated from the same source

The vertical cut is not a separate project. It comes out of the same render, in the same
run, from the same narration. If I had made it a second workflow, it would have drifted:
different intro, different loudness, different title convention. Two pipelines for the
same content is two pipelines to keep in sync, and one of them always loses.

One honest limitation, stated plainly: the short is currently the first 58 seconds of the
long cut, not a selected highlight. That is a known weakness and it is on the list. I
would rather ship a mediocre short automatically than a good one manually, because the
manual one does not happen on a week when I am busy.

The shape that generalizes

The specific thing here is video. The shape is not:

A repeated task that has an order to it.
One command that does the whole order.
A final step that measures the output and prints the number.

That third step is the one people skip, and it is the one that turns "the script said it
worked" into "the file is 443.1 seconds and 6.8 MB". Those are different claims, and only
one of them is evidence.

I build these pipelines to order — content production, ops automation, scheduled jobs.
Single file, zero third-party Python dependencies, and a final step that proves what it
produced. Available for hire on Fiverr.

Your check says PASS. It looked at zero files.

EL E — Sun, 27 Sep 2026 02:02:23 +0000

A verification step that finds nothing looks exactly like a verification step that
finds nothing wrong. Both print PASS. Both exit 0. Only one of them actually did
anything.

I shipped this bug three times in the same codebase before I understood the shape of it.

The bug

A scanner walked a directory and reported leaked secrets:

def main(paths):
    findings = []
    for root in paths:
        for f in glob.glob(root + "/**/*", recursive=True):
            findings += scan(f)
    print(f"files scanned: {len(seen)} | leaks: {len(findings)}")
    if findings:
        sys.exit(1)
    print("PASS")

It worked. For two months it printed PASS before every release.

Then I passed it a list of files instead of a directory. glob("some/file.mp4/**/*")
expands to nothing. Zero files scanned. Zero findings. PASS. Exit 0.

The caller was the release script. Every release for those two months had been
"verified" by a scanner that had looked at nothing at all.

Nothing errored. Nothing warned. The log line even told me the truth —
files scanned: 0 — and I had read past it every single time, because the word next
to it was PASS.

Why this class of bug survives

Most failures announce themselves. This one impersonates success.

Three properties make it durable:

The output is indistinguishable from the good case. A clean scan and a scan-of-nothing produce the same word.
It fails open. The guard is supposed to block. When it breaks, it stops blocking — which is silent by definition.
It gets more trusted over time. Every green run is evidence the check works. Two months of green is two months of accumulating false confidence.

That third one is the dangerous part. The longer it runs, the less anyone looks.

The fix is one line of policy, not one line of code

if scanned == 0:
    print("BLOCK: scanner matched zero files — refusing to report PASS")
    sys.exit(3)

A check that examined nothing must not be allowed to report success.

Note the distinct exit code. 1 means "found a problem". 3 means "could not do my
job". Those are different states and the caller should be able to tell them apart.
Collapsing them into "non-zero" throws away the one signal that would have caught this.

While I was there I added two more:

if missing_paths:
    print("BLOCK: path does not exist:", missing_paths)
    sys.exit(2)

print(f"[verify] files scanned: {scanned} | findings: {len(findings)}")

That last line runs on the success path. The happy path now has to state what it
looked at. If the number is zero, you see it at the moment you would otherwise be
reassured.

Where else this hides

Once you have the shape, you find it everywhere:

Check	Silent-zero failure
Test runner	Pattern matches no tests. "0 passed" is green in several runners.
Linter	Ignore file swallows the whole tree.
Backup verify	Compares a manifest that is itself empty.
Grep-based guard in CI	Typo in the pattern. Nothing matches. Gate opens.
Schema check	Config fails to parse, exception swallowed, empty dict validates fine.

That last one bit me too, separately: a JSON file written by PowerShell carried a
UTF-8 BOM. json.load(open(path, encoding="utf-8")) raised, the exception was
caught and turned into None, and a dashboard rendered an empty table instead of
an error. The table looked fine. It was just empty.

The fix there was encoding="utf-8-sig". The lesson was the same one: the failure
had a display mode that looked like a working system.

The rule I use now

When a check reports success, ask what it examined. If it cannot tell you a number,
it is not evidence.

Concretely, for anything that gates a release, a deploy, or a payment:

Print the denominator, not just the verdict.
Make "examined nothing" a distinct, failing state.
Use separate exit codes for "found a problem" and "could not run".
Write one regression test that feeds the checker an input matching nothing, and assert that it fails.

That last test is the one nobody writes. It is also the only one that would have
caught all three of my versions of this bug.

I packaged this as a tool

The guard above is four lines, but the rules around it (distinct exit codes, literal
paths that do not exist, counting from the check's own output) turned out to be worth
writing down once. It is one file, standard library only:

https://github.com/elwakeupman-shhh/zero-match-guard

# blocks instead of passing when the glob matched nothing
python zero_match_guard.py --paths "dist/**/*.js" -- npm run lint

It ships with the test nobody writes: feed the checker an input matching nothing, and
assert that it fails.

Why I care about this more than most

Almost everything I build is this kind of tool: a small script that watches something
and tells you whether it is fine. Health checks, integrity verification, log analysis,
scheduled monitors. The entire value of that category is that you stop looking, because
the script is looking for you.

Which means a monitor that lies is worse than no monitor. No monitor leaves you
uncertain, and uncertainty makes you check. A green dashboard makes you stop checking —
and then you find out two months later.

So now every one of my checks answers two questions instead of one:

Did you find a problem?
How many things did you look at?

I build single-file Python tools of exactly this kind: service and disk watchdogs,
integrity verification, log analysis, scheduled monitors. Zero third-party dependencies,
one file, meaningful exit codes — small enough that you can read the whole thing before
you trust it with anything. Available for hire on Fiverr.

Five single-file Python tools I actually run in production ops

EL E — Sat, 26 Sep 2026 09:47:24 +0000

Over years of doing infrastructure and security work, I kept writing the same
kind of thing: a single-file Python tool, no third-party dependencies, that does one
job well enough to drop into a cron job and forget about. No framework, no install
step, no virtualenv to maintain on a box you only SSH into twice a year.

Here are five of them, and — more importantly — the specific failure each one exists
to catch.

1. Disk and service health probe

The failure it catches: the two boring outages that actually take services down.
A data directory silently fills up until writes and database transactions start
failing, or a background process exits and nobody notices until a customer emails.

How it works: it takes a list of paths and a list of service/process names,
checks free-space percentage against a threshold and whether each process is alive,
prints a Markdown summary, and returns a non-zero exit code if anything breaches.
That exit code is the whole point — it makes the tool composable with any CI or cron
hook without writing glue.

python disk_service_probe.py \
  --paths C:/ D:/ E:/data \
  --services nginx postgres my-worker \
  --disk-threshold-percent 85 \
  --service-down-threshold 1

2. Directory SHA-256 integrity snapshot

The failure it catches: a config directory that drifts. Someone hotfixes a file
on the box during an incident, or a deploy half-applies, and three weeks later nobody
can say which files changed or when.

How it works: walk the tree, hash every file with SHA-256, serialise to a JSON
baseline. Later runs diff current state against that baseline and report added,
removed and modified files. No agent, no database, no daemon — the baseline is just
a file you can commit or archive.

# create the baseline
python dir_snapshot.py snapshot --dir ./configs --output baseline.json

# compare current state against it
python dir_snapshot.py verify --dir ./configs --snapshot baseline.json

The same idea, packaged properly with a hash chain so the record itself is
tamper-evident, is here:
offchain-integrity-verifier

3. USDT receipt verification gate

The failure it catches: trusting a webhook payload, or a screenshot, as proof
that a crypto payment arrived. Both are trivially forged, and by the time you find
out, you have already shipped.

How it works: it is a gate, not a notifier. It checks the claimed transfer
against public on-chain data — recipient address, confirmation depth, amount — and
emits a pass/fail verdict plus a tamper-evident receipt. Read-only: it never holds
a key and never sends a transaction.

python verify_cli.py --selftest

Source: usdt-receipt-verifier

4. Offline log analyser

The failure it catches: gigabytes of raw application log sitting on disk doing
nothing, because building a structured summary by hand with grep — error rates,
traffic troughs, repeated anomaly signatures — is tedious enough that nobody does it
until there is already an incident.

How it works: dependency-free parsing of common structured log formats,
frequency histograms bucketed by time, extraction of repeated anomaly signatures,
Markdown report out. Fully offline, so it is safe to point at logs you are not
allowed to ship to a third-party service.

python log_analyser.py /var/log/app/production.log --output report.md

5. Endpoint availability and latency check

The failure it catches: paying for an external monitoring SaaS to watch a handful
of internal endpoints — which means an account, an agent, an egress path, and alert
noise, for something you could answer in one command from inside the network.

How it works: feed it endpoints as plain text, CSV or JSON. It checks HTTP status
and round-trip time (optionally including transfer time), skips private IP ranges by
default as a safety guard, and writes a Markdown report. Any target failing gives you
a non-zero exit code.

python netcheck.py https://github.com https://cloudflare.com --timeout 5.0 --output netcheck.md

The pattern

Zero dependencies, single file, meaningful exit codes. That combination is what makes
these things survive: they run identically on staging and production, they need no
maintenance window to upgrade, and any of them can be read end to end in one sitting
before you trust it with anything.

Two of the five are published as proper open-source projects
(usdt-receipt-verifier,
offchain-integrity-verifier).
The other three are internal utilities — happy to share the approach if any of these
failure modes sound familiar; open an issue on either repo and I will answer there.

The tools themselves

All three are one file, standard library only, with a test you can run before you
trust them:

zero-match-guard — fail checks that examined nothing
usdt-receipt-verifier — verify USDT receipts offline
offchain-integrity-verifier — prove a report was not altered

Available for hire. I build this kind of tooling to order: ops automation, integrity
and verification tools, and content pipelines. Single file, zero third-party dependencies,
meaningful exit codes, and a test you can run yourself.
zerodeptools on Fiverr

Stop Trusting Screenshots: Verify Crypto Payments and Prove Your Reports Are Untouched

EL E — Fri, 04 Sep 2026 02:36:00 +0000

If you accept crypto (USDT-TRC20) for freelance or digital goods, you've probably been handed a "proof of payment" that was just a screenshot — editable, unverifiable, sometimes a fake TRC20 token.

Here are two open-source (MIT) tools I use to close that gap:

1. Verify the payment actually landed

usdt-receipt-verifier is read-only: give it your address + expected amount + min confirmations, and it checks the chain through a local Tor proxy (no real-IP leak), then writes a tamper-evident receipt. It issues no transaction and never sees your key.

2. Prove your deliverable report wasn't edited later

integrity-chain turns a report/attestation into a signed hash-chain. An independent verifier re-derives every link and flags tampering or "fake live" claims. Self-test shows honest chains PASS, tampered/fake-live FAIL.

Both are local-first, zero real IP, no keys.

Try it yourself — zero install, offline, no account

usdt-receipt-verifier — https://github.com/elwakeupman-shhh/usdt-receipt-verifier python usdt_receipt_verifier.py --selftest
integrity-chain — https://github.com/elwakeupman-shhh/offchain-integrity-verifier pip install -r requirements.txt then python verify_cli.py --selftest

Both exit 0 on honest data and non-zero on tampered/fake-live data — prove it yourself.

Contact: open a GitHub issue on either repo above.

The tools themselves

All three are one file, standard library only, with a test you can run before you
trust them:

zero-match-guard — fail checks that examined nothing
usdt-receipt-verifier — verify USDT receipts offline
offchain-integrity-verifier — prove a report was not altered