Un dos puntos de shell no hace nada. Úsalo de todos modos

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

Una publicación sobre el comando `:` de no operación del shell POSIX provoca un debate sobre si estos modismos tan breves son herramientas ingeniosas o riesgos para la legibilidad. Los comentaristas destacan usos prácticos de `:` para validar argumentos, hacer redirecciones y aplicar trucos de scripting, pero muchos argumentan que comprimir lógica de varias líneas en líneas únicas opacas hace que los scripts de shell sean más difíciles de mantener, especialmente a escala. El intercambio se amplía hacia una crítica del propio scripting en shell: sus trampas, peculiaridades de portabilidad y su papel en la era de Python, PowerShell y el código generado por LLMs.

Utilidad del comando : (null)

  • Muchos encuentran algunos modismos realmente útiles, especialmente para:
    • Validar argumentos/variables de entorno requeridos: ${1:?missing argument} o VAR="${VAR:?message}".
    • Proporcionar valores predeterminados: : "${DOTFILES_PATH:=$HOME/.dotfiles}".
    • Servir como marcador de posición en if/while cuando se requiere sintácticamente un comando.
    • Funcionar como una línea de “docstring” dentro de funciones o como un alias ficticio para facilitar el descubrimiento.
  • Otros ven la mayoría de los ejemplos como ingeniosos pero poco prácticos, y que básicamente solo comprimen código legible en líneas únicas.

Detalles sobre redirección, truncamiento y portabilidad

  • Algunos señalan que : >file tanto trunca como crea el archivo, algo que supuestamente el artículo subraya poco.
  • La discusión aclara que las redirecciones pueden funcionar sin :, pero el comportamiento difiere entre shells (por ejemplo, zsh imprimirá el contenido del archivo para < file a menos que se adjunte a :).
  • Ejemplos con subshell y sin subshell muestran distinto comportamiento bajo set -e / --posix, lo que justifica ( : < file ) en algunos contextos.
  • : es un builtin, mientras que true puede ser una utilidad externa; : ignora los argumentos de forma segura, así que a veces se prefiere.

Legibilidad frente a ingenio

  • Fuerte rechazo a convertir código multi-línea y comprensible en líneas únicas densas.
  • Varios sostienen que cualquier cosa más allá de scripts pequeños debería priorizar claridad y manejo explícito de errores, no concisión.
  • Algunos ven estos trucos como acertijos divertidos, apropiados para uso personal o código ofuscado, pero inaceptables en producción.

Shell frente a otros lenguajes (y LLMs)

  • Múltiples comentarios sostienen que la sintaxis del shell POSIX es fundamentalmente mala para programas grandes; se prefieren Python/Ruby/PowerShell para scripts mantenibles.
  • Otros defienden el shell como algo singularmente adecuado para automatización pequeña y orquestación de procesos, pese a sus rarezas, especialmente con herramientas como ShellCheck.
  • Se informa que los LLMs son buenos generando scripts complejos de shell/Perl, pero aún requieren revisión; la calidad y la sobreingeniería son quejas recurrentes.

Shells y ecosistemas alternativos

  • Menciones de fish, nushell, oil, zsh y especialmente PowerShell como opciones más modernas o expresivas, con debate sobre:
    • Tiempo de arranque y huella de dependencias.
    • Idoneidad como “shell del sistema” frente a lenguaje de scripting.
    • Verbosidad, complejidad y disponibilidad multiplataforma.