Tema: shell
-
Códigos de saída de find e xargs: o 0/>0 grosseiro do find versus a escala 123-127 do xargs
O find só garante 0 para sucesso total e qualquer valor acima de 0 para erro, de propósito sem mais detalhes, enquanto o xargs define uma escala específica para indicar como o comando invocado falhou: 123 para saída não zero comum, 124 para saída 255, 125 para morte por sinal, 126 para comando não executável e 127 para comando não encontrado. Encadear find com xargs num pipe significa verificar duas filosofias diferentes de código de saída no mesmo pipeline.
-
zsh como shell padrão do macOS: o que quebra em um script escrito para bash
Desde o macOS 10.15, o zsh é o shell de login e interativo padrão do macOS. Um script que presume a divisão de palavras do bash, arrays começando em zero ou globbing tolerante pode se comportar de outro modo, ou falhar por completo, na sessão interativa zsh de um agente em um Mac, mesmo sem considerar a idade do próprio /bin/bash.
-
grep, diff, cmp e test/[: o código de saída 1 significa «não encontrado», não falha
grep, diff, cmp e o builtin test/[ usam a mesma escala de três valores: 0 para resultado positivo, 1 para resultado negativo que não é erro, e 2 (ou >1) para problema real. Interpretar o 1 como falha do script é o erro de leitura mais comum de um agente com essas ferramentas.
-
grep e ripgrep na busca em código: recursão, filtros e códigos de saída
O GNU grep busca recursivamente com -r, restringe a busca com --include e --exclude-dir e encerra com 0, 1 ou 2 para correspondência, nenhuma correspondência ou erro; o ripgrep faz o mesmo por padrão, mas ignora arquivos ignorados pelo git, ocultos e binários. Saiba o que cada ferramenta ignora antes de confiar em um resultado vazio.
-
Armadilhas de locale e data no coreutils: LC_ALL, intervalos de caracteres e date do GNU versus BSD
O locale altera silenciosamente a ordem de classificação, o que [a-z] reconhece, os separadores decimais e o formato de data padrão; os scripts devem definir LC_ALL=C (ou C.UTF-8) e TZ explicitamente, pedir formatos de data explícitos e evitar date -d (só GNU) ou date -v (só BSD), a menos que a plataforma seja conhecida.
-
sort, uniq e comm: operações de conjuntos em texto que dependem de entrada ordenada
O uniq só colapsa duplicatas adjacentes, o comm exige que as duas entradas estejam ordenadas na mesma collation e a ordem do sort segue LC_COLLATE; execute esses pipelines com LC_ALL=C, escolha as opções de chave corretas (-n, -h, -V, -k, -t) e use comm -12 e comm -23 para interseções e diferenças.
-
"exec format error" e "cannot execute binary file": incompatibilidades de arquitetura e de shebang
O erro ENOEXEC do kernel aparece como "exec format error" ou "cannot execute binary file: Exec format error" quando a arquitetura da CPU não corresponde ou o script não tem um shebang utilizável; finais de linha CRLF no shebang causam uma falha parecida, com "bad interpreter" ou "required file not found". O artigo mostra como distingui-los com file(1) e corrigir cada caso sem adivinhação.
-
find e xargs sem surpresas: nomes separados por NUL, -exec + e simulações prévias
Nomes de arquivo podem conter espaços e quebras de linha; por isso, passe-os do find para outros programas com -print0 e xargs -0 (ou find -exec ... {} +), teste a seleção com -print antes de acrescentar -delete e use xargs -r para que uma lista vazia não execute nada.
-
Trabalhando com JSON na linha de comando com o jq
O jq lê JSON, aplica um filtro e imprime o resultado: use -r para strings simples, -c para um objeto por linha, --arg e --argjson para passar valores com segurança, -e para transformar null ou false em código de saída, e select, map e to_entries para remodelar dados; nunca monte filtros por concatenação de strings.
-
Como escrever scripts de shell que falham de forma segura
Use set -euo pipefail, coloque aspas em toda expansão, prefira [[ ]] e arrays, verifique os scripts com o ShellCheck e evite interpretar a saída de ls; um script que para no primeiro erro é mais confiável do que um que continua.
-
Script de configuração do primeiro dia que se verifica sozinho: bootstrap, doctor e smoke test
Um único comando após o clone produz um ambiente funcional ou uma lista precisa do que falta e de como corrigir: um script doctor somente leitura verifica cada requisito, um bootstrap idempotente instala apenas o que as verificações apontam como ausente e um smoke test define o status de saída. O CI executa tudo a partir de uma máquina limpa, para que o script não se deteriore entre um recém-chegado e outro.
-
"Argument list too long" (E2BIG) e o limite ARG_MAX
Um comando de shell que se expande para argumentos demais falha com 'Argument list too long', o erro E2BIG de execve(2) causado pelo limite ARG_MAX do kernel. O artigo mostra como medir o limite e como substituir um glob que falha por lotes com xargs ou com find -exec ... +, em vez de tentar contornar o problema com aspas.
-
sed e awk para edições orientadas a linhas: substituição, campos e alterações in-place
O sed aplica comandos de edição, principalmente s/regexp/replacement/, a cada linha; o awk divide as linhas em campos e executa pares padrão-ação. Use sed para substituições e remoções, awk para trabalho com colunas e pequenas agregações, e trate com cuidado -i, -n e as diferenças entre GNU e BSD.
Legível por máquina: JSON