La tilde en tu PATH puede no ser tu HOME

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

Usar `~` en comandos de shell —especialmente al modificar el `PATH`— puede comportarse de forma muy distinta a lo que muchos usuarios esperan, porque la expansión de tilde solo ocurre en posiciones específicas sin comillas y varía entre shells POSIX y extensiones de Bash/Zsh. Los comentaristas comparten errores como insertar accidentalmente una `~` literal en `PATH` o incluso borrar `$HOME`, debaten si los directorios locales del usuario deben preceder a las rutas del sistema, y contrastan las muchas “trampas” de Bash con shells alternativos como fish, nushell y zsh. El intercambio destaca cómo las reglas sutiles de comillas y expansión, junto con herramientas y documentación inconsistentes, hacen que el uso robusto del shell y la escritura de scripts sea más difícil de lo que parece.

Expansión de tilde y comportamiento de PATH

  • La tilde se expande solo en posiciones específicas (al inicio de una “palabra” sin comillas; en algunos shells también después de dos puntos sin comillas en asignaciones).
  • Poner comillas a ~ impide la expansión y puede dejar una ~ literal en PATH, que es el problema original.
  • Algunos shells (zsh, fish) ofrecen formas más convenientes o basadas en arrays de añadir ~/.local/bin a PATH que gestionan correctamente la expansión.
  • Varios comentaristas prefieren usar $HOME en lugar de ~ en scripts para evitar sorpresas.

Reglas de comillas y trampas comunes de shell

  • Malentender cuándo poner comillas es una fuente importante de errores: la gente tanto pone demasiadas comillas como demasiado pocas.
  • Orientación ofrecida:
    • Pon siempre comillas a las expansiones de variables ("$var") en los argumentos para evitar la separación por espacios y la expansión de globos.
    • Usa comillas simples solo para cadenas literales que contengan caracteres especiales.
  • La expansión de variables y la expansión de tilde se comportan de manera distinta; tratarlas igual lleva a errores.

Orden y seguridad de PATH

  • Debate sobre si anteponer o posponer directorios de usuario como ~/.local/bin.
    • Un bando: posponerlos para que los binarios del sistema tengan prioridad, reduciendo el riesgo de sustituciones maliciosas.
    • El otro: anteponerlos para que los usuarios puedan sobrescribir intencionadamente herramientas del sistema obsoletas.
  • Consenso en que, si un atacante puede escribir en los directorios de tu PATH, ya existe una brecha grave.

POSIX frente a comportamiento específico del shell

  • Algunos comportamientos del artículo dependen de extensiones de bash/zsh y no son portables a /bin/sh (a menudo dash o ash).
  • Se citaron las reglas POSIX de expansión de tilde; al principio hubo confusión, y luego se aclaró que la expansión después de : sin comillas en asignaciones está permitida.
  • Varios recordatorios para distinguir entre “bashisms” y construcciones estrictamente conformes a POSIX.

Shells alternativas y elecciones de lenguaje

  • Muchos critican bash como un lenguaje de script “terrible” o frágil, con demasiados casos límite.
  • Se mencionaron alternativas: fish, zsh, nushell, murex, PowerShell, Perl, Ruby, etc.
  • Contraargumento: bash/sh siguen dominando porque vienen preinstalados en todas partes, especialmente en sistemas remotos.

Nombres de archivo, caracteres y robustez

  • Algunos sostienen que la vida sería más fácil si las rutas solo permitieran un conjunto ASCII restringido, para evitar problemas de codificación y análisis.
  • Otros defienden con firmeza el soporte para escrituras no latinas y Unicode arbitrario, a pesar de los dolores de cabeza en las herramientas.
  • El uso de espacios o de - al inicio en los nombres de archivo se señala como una fuente frecuente de errores y trampas de seguridad.

Entorno, HOME y depuración

  • Se señaló la distinción entre $HOME y el home de la cuenta en las bases de datos del sistema; estos pueden divergir y confundir la resolución de ~.
  • Manipular HOME para pruebas puede chocar con herramientas que resuelven los directorios home de forma diferente.
  • Las grandes organizaciones suelen tener archivos de inicio de shell profundamente encadenados, lo que dificulta rastrear dónde se establecen las variables; se recomendaron herramientas de trazado para el arranque del shell.

Historias de guerra y lecciones

  • Varias anécdotas: crear un directorio literal ~, ejecutar accidentalmente rm -r ~, y herramientas de IA creando directorios ~.
  • Lecciones extraídas: evita rm -r cuando sea posible, usa rutas más explícitas (./~), y trata las características del shell con cautela.