Vamos usar opções longas em scripts

• Muitos utilitários de linha de comando oferecem suporte a opções no formato curto (-f) e no formato longo (--force)
• O formato curto é para uso interativo; em scripts, recomenda-se usar o formato longo
• Por exemplo, no terminal, você digita $ git switch -c my-new-branch
• Em um script de release, escreva assim:
  • try shell.exec("git fetch origin --quiet", .{});
  • try shell.exec("git switch --create release-{today} origin/main", .{ .today = stdx.DateUTC.now() }, );
• As opções no formato longo são muito mais descritivas para quem lê

[GN⁺]

Comentários do Hacker News

• Eu prefiro opções longas, mas quando é preciso chamar comandos POSIX de forma portável, opções curtas são a única escolha. O POSIX não especifica opções longas

  • Por exemplo, você pode consultar a especificação do diff
  • Na maioria dos casos, usar bindings de biblioteca é uma alternativa melhor do que depender de utilitários POSIX
  • Em vez de chamar grep, pode ser mais eficiente usar algo como libpcre
  • Em utilitários não POSIX como git, hg, rg, ag etc., faz sentido usar opções longas

• Não se deve misturar interpolação de strings com execução de comandos

  • É preciso ter cuidado especialmente quando o comando é processado pelo shell
  • Em qualquer linguagem, deve-se usar uma API de execução baseada em listas ou arrays para passar os argumentos diretamente para execv(2), execvp(2) etc.

• Concordo que se deve usar opções longas, mas é preciso considerar a portabilidade

  • Nem todas as distribuições BSD oferecem suporte a opções longas no estilo GNU
  • Se você quer portabilidade, deve usar opções curtas

• Não se esqueça de usar -- depois de todas as opções e antes dos argumentos dinâmicos

• Antes de chamar um comando, deve-se verificar se o comprimento do comando é maior que ARG_MAX

  • Por exemplo, quando há um comando como este:
    • grep --ignore-case --files-with-matches -- "hello" *.c
  • Deve ser chamado assim:
    • CMD="grep --ignore-case --files-with-matches -- \"hello\" *.c"
    • ARG_MAX=$(getconf ARG_MAX)
    • CMD_LEN=${#CMD}
    • if (( CMD_LEN > ARG_MAX )); then
    • echo "Error: Command length ($CMD_LEN) exceeds ARG_MAX ($ARG_MAX)." >&2
    • exit 1
    • fi
    • eval "$CMD" # aviso: avalia os nomes de arquivos

• Concordo com essa abordagem. Outra vantagem é que fica mais fácil procurar no man page com grep o que cada opção faz

• Se você quiser tornar um script portável para outros sistemas POSIX, talvez precise usar opções curtas

  • Opções longas não são padronizadas
  • Você mesmo precisa decidir esse trade-off

• As opções devem ficar em linhas separadas para facilitar o acompanhamento e o git blame

• Esta é uma das regras básicas ao escrever scripts. Se houver opção longa disponível, ela deve ser usada

  • Isso é simplesmente sensato demais

• Opções no formato longo são muito mais descritivas para o leitor

  • Há menos chance de erros de digitação