Criando Modelos de Script Bash Reutilizáveis para Eficiência

Modelos de script Bash reutilizáveis ajudam você a parar de reescrever as mesmas verificações de segurança toda vez que automatiza uma tarefa. Um bom modelo fornece ao seu script tratamento de erros rigoroso, registro previsível, ajuda de uso, análise de argumentos e ganchos de limpeza antes de adicionar lógica específica do projeto.

O objetivo não é um grande framework. É um pequeno ponto de partida que mantém os scripts de rotina consistentes e mais fáceis de depurar.

Por que Usar Modelos de Script?

Modelos são úteis quando sua equipe escreve muitos scripts pequenos para backups, implantações, relatórios, limpeza de logs ou movimentação de dados. Sem um modelo, cada script tende a lidar com erros, opções e registro de forma um pouco diferente.

Um modelo reutilizável oferece:

• Modo estrito consistente e hábitos de citação.
• Uma função usage padrão.
• Um lugar para auxiliares de registro.
• Um gancho de limpeza para arquivos temporários e locks.
• Análise previsível de linha de comando com getopts.

As Peças Centrais do Modelo

Comece com o próprio Bash, depois ative o comportamento estrito:

#!/usr/bin/env bash
set -euo pipefail

set -e sai em muitas falhas de comando não tratadas, set -u trata variáveis não definidas como erros, e set -o pipefail captura falhas dentro de pipelines. Você ainda precisa de verificações explícitas para falhas que espera, mas o modo estrito captura muitos erros acidentais.

Adicione um nome de script e um pequeno bloco de uso:

readonly SCRIPT_NAME="$(basename "$0")"

usage() {
    cat <<USAGE
Uso: $SCRIPT_NAME [-v] [-o diretorio_saida] arquivo_entrada

Opções:
  -v              Ativar registro verboso
  -o diretorio_saida   Escrever saída neste diretório
  -h              Mostrar esta mensagem de ajuda
USAGE
}

Use pequenos auxiliares de registro em vez de chamadas echo espalhadas:

log_info() {
    [[ "$VERBOSE" -eq 1 ]] && printf '[INFO] %s\n' "$1"
}

die() {
    printf '[ERROR] %s\n' "$1" >&2
    exit 1
}

Se o script criar arquivos temporários ou arquivos de lock, adicione uma função de limpeza no início:

cleanup() {
    # Remover arquivos temporários ou liberar locks aqui.
    :
}

trap cleanup EXIT

Análise Segura de Argumentos com getopts

A maioria dos modelos reutilizáveis precisa de flags. O getopts embutido do Bash é suficiente para opções curtas como -v e -o diretorio_saida.

VERBOSE=0
OUTPUT_DIR="."

while getopts ":vo:h" opt; do
    case "$opt" in
        v) VERBOSE=1 ;;
        o) OUTPUT_DIR=$OPTARG ;;
        h) usage; exit 0 ;;
        :) die "A opção -$OPTARG requer um argumento" ;;
        \?) die "Opção desconhecida: -$OPTARG" ;;
    esac
done
shift "$((OPTIND - 1))"

INPUT_FILE=${1:-}
[[ -n "$INPUT_FILE" ]] || { usage >&2; exit 1; }
[[ -f "$INPUT_FILE" ]] || die "Arquivo de entrada não encontrado: $INPUT_FILE"

O : inicial em ":vo:h" permite que seu script lide com argumentos de opção ausentes por conta própria. Após a análise, shift "$((OPTIND - 1))" remove as opções analisadas para que os argumentos posicionais sejam mais fáceis de ler.

Um Modelo Compacto que Você Pode Reutilizar

Aqui está um ponto de partida prático para scripts de operações pequenos:

#!/usr/bin/env bash
set -euo pipefail

readonly SCRIPT_NAME="$(basename "$0")"
VERBOSE=0
OUTPUT_DIR="."

usage() {
    cat <<USAGE
Uso: $SCRIPT_NAME [-v] [-o diretorio_saida] arquivo_entrada
USAGE
}

log_info() {
    [[ "$VERBOSE" -eq 1 ]] && printf '[INFO] %s\n' "$1"
}

die() {
    printf '[ERROR] %s\n' "$1" >&2
    exit 1
}

cleanup() {
    :
}
trap cleanup EXIT

while getopts ":vo:h" opt; do
    case "$opt" in
        v) VERBOSE=1 ;;
        o) OUTPUT_DIR=$OPTARG ;;
        h) usage; exit 0 ;;
        :) die "A opção -$OPTARG requer um argumento" ;;
        \?) die "Opção desconhecida: -$OPTARG" ;;
    esac
done
shift "$((OPTIND - 1))"

INPUT_FILE=${1:-}
[[ -n "$INPUT_FILE" ]] || { usage >&2; exit 1; }
[[ -f "$INPUT_FILE" ]] || die "Arquivo de entrada não encontrado: $INPUT_FILE"
mkdir -p "$OUTPUT_DIR"

log_info "Processando $INPUT_FILE"
# Adicione sua lógica de script aqui.

Mantenha o modelo curto. Adicione funções compartilhadas apenas quando vários scripts realmente precisarem delas. Um modelo deve remover o trabalho repetitivo de configuração, não fazer cada script parecer um framework.