Diretrizes de interface de linha de comando (2021)

Artigo original ↗ Discussão no Hacker News ↗

O design de interfaces de linha de comando é retratado como estando em uma “idade de ouro”, mas também limitado por décadas de convenções inconsistentes, desde flags POSIX e `getopt` até mega-CLIs idiossincráticas como `git` e `kubectl`. Os participantes avaliam os trade-offs entre CLIs, TUIs e GUIs, debatendo questões de usabilidade como descobribilidade, padrões seguros para comandos destrutivos, modos `--dry-run`, formatação de saída (JSON, cor, emoji), comportamento de ajuda e o uso correto de stdout versus stderr. Há amplo apoio a diretrizes mais claras e consistentes e a ferramentas melhores (incluindo recursos no estilo PowerShell e tratamento de segredos), junto com ceticismo de que a cadeia de ferramentas Unix legada e os scripts existentes possam ser facilmente remodelados para atender aos ideais modernos de UX.

CLI vs TUI vs GUI

  • Alguns argumentam que TUIs são ideais para o “público geral”: tamanho de fonte consistente, layouts densos, porém estruturados, eficiência com teclado e facilidade de uso via SSH.
  • Outros contrapõem que TUIs compartilham muitas desvantagens das GUIs, não são mais fáceis de descobrir, e que GUIs bem projetadas podem imitar a estrutura de uma TUI sem as restrições do terminal.
  • Vários observam que as CLIs estão em uma “idade de ouro” em números absolutos de usuários, mas debatem se elas são mais importantes em relação a todos os usuários de computador.

Shells, composição e ferramentas POSIX

  • Debate sobre se os comandos Unix foram criados principalmente para uso programático ou para uso interativo em shell; há consenso de que shells são linguagens de programação, mas não são ideais para programas grandes.
  • Forte apoio à ideia de “shell como cola”: pequenos scripts de shell que orquestram C ou outros binários podem substituir programas muito maiores.
  • getopt do POSIX é amplamente citado, mas esclarece-se que é um recurso do POSIX, não da linguagem.

Convenções de design de linha de comando e pontos de atrito

  • Visões divergentes sobre hierarquias aninhadas de subcomandos: elas podem reduzir a complexidade local, mas tornam a descoberta mais difícil em comparação com uma única grande página de ajuda.
  • Reclamações sobre inconsistência na capitalização de flags e flags curtas combinadas; alguns gostariam que novas ferramentas favorecessem flags longas e explícitas e evitassem semânticas complicadas de opções curtas.
  • Apelos para evitar abreviações arbitrárias de subcomandos, especialmente em scripts, para preservar a extensibilidade futura.
  • Alguns acham o documento de diretrizes longo; outros o veem como conciso em relação aos guias de UI típicos.

Saída legível por máquina e formatos

  • A tensão entre CLIs legíveis por humanos e por máquina é chamada de “quebrada por design”; sugestões incluem modos --json e/ou variáveis de ambiente para formato de E/S.
  • Há preocupação de que variáveis de ambiente possam tanto simplificar o controle global quanto introduzir bugs sutis ou inchaço.
  • O PowerShell é citado como uma solução parcial com saída estruturada, mas também criticado por ser verboso e às vezes difícil de usar.

Segurança, dry run e comandos destrutivos

  • Forte apoio a --dry-run / comportamento de “what-if”, às vezes até como padrão exigindo um --execute/--commit explícito.
  • Padrões sugeridos:
    • Ferramentas que apenas emitem comandos de shell, permitindo que os usuários inspecionem/editem e depois façam pipe para sh.
    • Sandboxing no estilo try via sistemas de arquivos overlay.
  • Alguns reimplementam utilitários centrais para adicionar prompts de segurança; outros preferem aliases de shell com -i.

Tratamento de segredos

  • A diretriz contra segredos em variáveis de ambiente é debatida.
  • Alternativas discutidas: arquivos de credenciais com permissões estritas, credenciais do systemd e ganchos do tipo “execute este comando para buscar o segredo” que podem delegar a gerenciadores de senhas ou serviços.
  • Gerenciadores de segredos são vistos como convenientes em ambientes gerenciados; menos claro para projetos pessoais.

Ajuda, documentação e descoberta

  • Frustração com ferramentas que rejeitam -? ou similar como ajuda em vez de simplesmente imprimir o uso.
  • Alguns se decepcionam porque as diretrizes apenas dizem para “considerar” páginas man; outros observam que páginas man e --help ricos continuam cruciais para CLIs grandes.

Stdout/stderr e UX da saída

  • Forte argumento de que todo logging, progresso, animações e mensagens de status devem ir para stderr; stdout deve ser reservado para o “resultado principal” para manter pipelines confiáveis.
  • Animações em stdout não-TTY, em particular, são criticadas por quebrar logs; alguns dizem que animações nunca deveriam estar no stdout.
  • Emojis e símbolos decorativos dividem opiniões: alguns os consideram úteis e fáceis de escanear visualmente; outros não gostam da inconsistência, dos problemas de renderização em terminais e da frivolidade percebida, sugerindo que sejam opcionais e redundantes com texto.

Versionamento, descontinuação e complexidade de CLI

  • A descontinuação em CLI é vista como particularmente difícil porque os comandos são imediatamente usados em scripts e carecem de semânticas de fixação de versão comuns em bibliotecas.
  • São discutidos contornos como copiar binários para caminhos privados, mas isso é criticado por ser frágil devido às dependências.
  • O crescimento das “mega-CLIs” (por exemplo, ferramentas com múltiplos subcomandos) é lamentado como um afastamento do ethos Unix clássico de “faça uma coisa bem”, mas também é reconhecido como uma resposta prática à complexidade moderna.