自分が書いたものを、自分で検算してはいけない ── 測定器を変えると出てくる 3 つの穴

【技術コラム】検算は「別の言語・別のツール」でやる

検算の独立性は、手順の独立性ではなく道具の独立性で決まる。

同じ言語・同じライブラリで検算すると、書き込み側の癖が、そのまま検算側にも入る。

# ❌ Python で書いて、Python で数える
python write.py && python verify.py

# ✅ Python で書いて、外部のコマンドで数える
python write.py
file            target.txt        # 🔬 改行コードの種別（Python の open では見えない）
wc -l         < target.txt        # 🔬 行数
grep -c '^## ' target.txt         # 🔬 見出し数
md5sum          target.txt        # 🔬 バイト単位のハッシュ

特に効くのが file と od だ。どちらも「バイト列を、意味を付けずに見る」道具になっている。

# 末尾の 16 バイトを、そのまま見る
tail -c 16 target.txt > /tmp/t.bin; echo "exit=$?"
od -c /tmp/t.bin
rm -f /tmp/t.bin
#   \r  \n   → CRLF（正常）
#   \r  \r  \n → 🔴 二重 CR（今回の形）
#   \n         → LF

改行コードの判定は、単一の道具では決まらない。

# 🔴 grep -c $'\r' は、環境によって偽陰性を返す（0 件と出ることがある）
# ✅ file と od の 2 経路で確かめる
file target.txt
python -c "raw=open('target.txt','rb').read(); crlf=raw.count(b'\r\n'); print('CRLF',crlf,'bare LF',raw.count(b'\n')-crlf,'bare CR',raw.count(b'\r')-crlf)"

⚠️ そして、バイトで読み書きする規律（'rb' / 'wb'）は、既存部分を守る。新しく足す部分の改行までは守らない。 足すときは、貼る先の改行コードを測ってから組み立てること。

【技術コラム】cron が「動いたか」を、ログ以外で測る

# ① システム側の cron ログで、起動回数を数える
grep -c 'target-script' /var/log/cron > /tmp/c.txt; echo "exit=$?"
cat /tmp/c.txt; rm -f /tmp/c.txt

# 🔍 陽性対照: 正常に動いていると分かっている別の cron を、同じ針で数える
#    → 同じくらいの回数なら「起動はしている」
#    → 🔴 陽性対照まで 0 なら、針か走査先が間違っている

# ② systemd timer なら
systemctl list-timers --all > /tmp/t.txt; echo "exit=$?"
grep 'target' /tmp/t.txt; rm -f /tmp/t.txt

# ③ 「動いた形跡」を、出力ファイルの mtime で測る
stat -c '%y %n' /path/to/output/*.json

そして、いちばん確実なのは「装置に完了マーカーを書かせる」ことだ。

# バッチの最後に 1 行
date '+%Y-%m-%d %H:%M:%S' > /var/run/mybatch.done

# 確認する側
stat -c '%y' /var/run/mybatch.done

「起動した」と「完走した」は別の状態で、後者は装置自身にしか書けない。

⚠️ 背景実行は、死んでも何も言わない。起動直後に落ちたプロセスと、まだ走っているプロセスは、外から見て同じ「静か」に見える。

【技術コラム】パイプが隠すもの

長い出力を切るとき、| tail や | head を使うのは自然な動作だ。だがこれには 2 つの副作用がある。

(a) 見えなくなる

上の話がそれだ。切ったことに気づかない。エラーも出ない。

(b) exit code が置き換わる

こちらの方が深刻だ。

# ❌ 失敗しても exit=0 になる
heavy-scan.sh | tail -20
echo $?     # 🔴 tail の exit code。heavy-scan.sh が落ちても 0

# ✅ リダイレクトで受けて、exit code を素で見る
heavy-scan.sh > /tmp/out.txt 2>&1; echo "exit=$?"
tail -20 /tmp/out.txt        # 見るのは、exit code を確かめた【後】
rm -f /tmp/out.txt

⚠️ 正確に言うと、パイプが隠すのは「前段」の exit code だけだ。最後の 1 段が落ちれば、それは見える。 set -o pipefail で前段の失敗も拾えるが、それは規律であって構造ではない。付け忘れる。リダイレクトなら、そもそもパイプが無い。

そして、重い走査ではもう一段 悪い形が出る ── タイムアウトで殺されても「0 件」が返る。

exit=124 のときの「0 件」は、「無い」ではなく「最後まで見ていない」という意味だ。

⚠️ この形については、同じ日に公開したもう 1 本で詳しく書いた。「0 件」は、合格と見分けがつかない の技術コラムを参照してほしい。