Guías de interfaz de línea de comandos (2021)

Artículo original ↗ Discusión en Hacker News ↗

El diseño de interfaces de línea de comandos se presenta como en una “edad de oro”, pero también limitado por décadas de convenciones inconsistentes, desde las banderas POSIX y `getopt` hasta mega-CLIs idiosincráticas como `git` y `kubectl`. Los participantes sopesan las ventajas y desventajas de las CLI, TUI y GUI, debatiendo problemas de usabilidad como la descubribilidad, los valores predeterminados seguros para comandos destructivos, los modos `--dry-run`, el formato de salida (JSON, color, emoji), el comportamiento de ayuda y el uso correcto de stdout frente a stderr. Hay un amplio apoyo a directrices más claras y coherentes, así como a mejores herramientas (incluidas funciones al estilo PowerShell y la gestión de secretos), junto con escepticismo sobre si la cadena de herramientas Unix heredada y los scripts existentes pueden remodelarse fácilmente para cumplir los ideales modernos de UX.

CLI vs TUI vs GUI

  • Algunos sostienen que las TUI son ideales para la “audiencia general”: tamaño de fuente consistente, diseños densos pero estructurados, eficiencia con el teclado y facilidad de uso por SSH.
  • Otros replican que las TUI comparten muchos inconvenientes de las GUI, no son más fáciles de descubrir, y que las GUI bien diseñadas pueden imitar la estructura de una TUI sin las restricciones del terminal.
  • Varios señalan que las CLI están en una “edad de oro” en números absolutos de usuarios, pero debaten si son más importantes en relación con todos los usuarios de computadoras.

Shells, composición y herramientas POSIX

  • Debate sobre si los comandos Unix estaban pensados principalmente para uso programático o para uso interactivo en la shell; hay acuerdo en que las shells son lenguajes de programación, pero no son ideales para programas grandes.
  • Fuerte apoyo a la “shell como pegamento”: pequeños scripts de shell que orquestan C u სხვა binarios pueden reemplazar programas mucho más grandes.
  • POSIX getopt se menciona ampliamente, pero se aclara que es una característica de POSIX, no del lenguaje.

Convenciones de diseño de línea de comandos y puntos dolorosos

  • Opiniones divididas sobre las jerarquías anidadas de subcomandos: pueden reducir la complejidad local, pero hacen más difícil el descubrimiento frente a una gran página de ayuda.
  • Quejas sobre la inconsistencia en la capitalización de banderas y los indicadores cortos combinados; algunos desearían que las nuevas herramientas favorecieran banderas largas y explícitas y evitaran semánticas complicadas de opciones cortas.
  • Llamados a evitar abreviaciones arbitrarias de subcomandos, especialmente en scripts, para preservar la extensibilidad futura.
  • Algunos sienten que el documento de directrices es largo; otros lo ven conciso en comparación con las guías de UI típicas.

Salida legible por máquina y formatos

  • La tensión entre CLI legibles por humanos y por máquinas se califica como “rota por diseño”; se sugieren modos --json y/o variables de entorno para el formato de E/S.
  • Preocupa que las variables de entorno puedan simplificar el control global, pero también introducir errores sutiles o inflar la complejidad.
  • PowerShell se plantea como una solución parcial con salida estructurada, pero también se critica por ser verboso y a veces difícil de usar.

Seguridad, dry run y comandos destructivos

  • Fuerte apoyo a --dry-run / comportamiento “what-if”, a veces incluso como valor predeterminado que requiere un --execute/--commit explícito.
  • Patrones sugeridos:
    • Herramientas que solo emiten comandos de shell, permitiendo a los usuarios inspeccionarlos/editarlos y luego canalizarlos a sh.
    • Aislamiento estilo try mediante sistemas de archivos superpuestos (overlay).
  • Algunos reimplementan utilidades básicas para añadir avisos de seguridad; otros prefieren alias de shell con -i.

Gestión de secretos

  • Se debate la directriz contra secretos en variables de entorno.
  • Se discuten alternativas: archivos de credenciales con permisos estrictos, credenciales de systemd y ganchos de “ejecuta este comando para obtener el secreto” que pueden delegar en gestores de contraseñas o servicios.
  • Los gestores de secretos se ven como convenientes en entornos administrados; menos claro en proyectos personales.

Ayuda, documentación y descubribilidad

  • Frustración con herramientas que rechazan -? o similar como ayuda en lugar de imprimir simplemente el uso.
  • Algunos se decepcionan de que las directrices solo digan “considerar” páginas man; otros señalan que las páginas man y un --help rico siguen siendo cruciales para grandes CLI.

Stdout/stderr y UX de salida

  • Fuerte argumento de que todo el registro, el progreso, las animaciones y los mensajes de estado pertenecen a stderr; stdout debería reservarse para el “resultado principal” para mantener fiables las canalizaciones.
  • Las animaciones en stdout no interactivo en particular se critican por romper registros; algunos dicen que las animaciones nunca deberían estar en stdout.
  • Los emojis y símbolos decorativos dividen opiniones: algunos los encuentran útiles y fáciles de escanear visualmente; otros no gustan de la inconsistencia, los problemas de renderizado en terminal y la frivolidad percibida, sugiriendo que sean opcionales y redundantes con texto.

Versionado, deprecación y complejidad de la CLI

  • La deprecación en CLI se considera especialmente difícil porque los comandos se automatizan de inmediato y carecen de semánticas de fijación de versión comunes en las bibliotecas.
  • Se discuten soluciones como copiar binarios a rutas privadas, pero se critican por ser frágiles debido a las dependencias.
  • Se lamenta el crecimiento de las “mega-CLIs” (p. ej., herramientas con múltiples subcomandos) como una desviación del clásico ethos Unix de “haz una cosa y hazla bien”, aunque también se reconoce como una respuesta práctica a la complejidad moderna.