No pongas la tilde en tu PATH
Don't Put Tilde In Your Path
Al usar la herramienta de sandboxing nono, el autor descubrió que añadir ~/.local/bin/ a PATH no expande la tilde, sino que crea un directorio literal ./~/.local/bin/. Esto permite que un binario malicioso se ejecute desde el directorio actual. La solución es usar $HOME en lugar de ~. El artículo explica cómo verificar y corregir este error en .bashrc, .zshrc o .profile.
Como podemos ver, el binario kek fue encontrado y ejecutado desde ./~/.local/bin/ — el directorio home nunca estuvo involucrado.
- SoftTalker
Nunca uso tilde en los scripts, solo como una conveniencia al escribir comandos de forma interactiva.
$HOME en caso contrario, que todavía tiene trampas pero son las mismas que cualquier otra variable de entorno.
- amarshall
O simplemente puedes… no poner la tilde entre comillas. La gente siempre parece poner "cadenas" entre comillas en Bash por reflejo sin darse cuenta de que (casi) todo es una cadena y la mayoría de las cadenas no van entre comillas y sería raro hacerlo (p. ej., nadie escribe `"ls" "-a" "foo"`).
- thefilmore
Puedes simplemente hacer:
PATH=~/.local/bin:$PATH
PATH ya está exportado. Las comillas tampoco son necesarias para las asignaciones.
- FeepingCreature
¿No deberías haberte dado cuenta de esto porque tu PATH ~/.local/bin no funcionaba?
- alexpotato
No necesariamente sobre tildes, sino sobre algunas de las locuras que pueden pasar con bash en grandes organizaciones:
En un trabajo anterior, estaba tratando de averiguar qué parte de mi bashrc estaba estableciendo una variable de entorno en particular. Asumí que debía ser algún tipo de valor predeterminado instalado en mi perfil de usuario y/o heredado de /etc/<algo>.
Me di cuenta rápidamente de que mi bashrc estaba importando algunos otros archivos. De nuevo, la suposición era que esto sería un archivo de profundidad en la importación.
Resultó que había más de 10 capas de importación comenzando desde un "ur-bashrc" y luego capa tras capa de más y más importaciones para finalmente llegar a un perfil de nivel de usuario.
Era tan enrevesado que me estaba volviendo loco hasta que encontré esta publicación en Stack Exchange: https://unix.stackexchange.com/questions/813/how-to-determin...
Activa el "tracing" para las importaciones de bash para que luego puedas acotar dónde se está estableciendo la variable de entorno.
- dspillett
Iba a decir "siempre parece funcionar para mí" y luego vi "… en realidad funciona en Bash y Zsh, porque …".
Otro bashismo que debo tener cuidado de no usar cuando intento ser portable.
Vale la pena señalar que en muchos sistemas /bin/sh no es bash (ni zsh), así que si quieres depender de bashismos (o simplemente no puedes molestarte en buscarlos) sé específico y usa "#!/bin/bash" para tu hashbang. En Debian y similares, por ejemplo, normalmente es dash.
- the__alchemist
Desearía que las distribuciones de Linux incluyeran un programa "Terminal"/"CLI" etc. que esté desacoplado del lenguaje de scripting. Tener una variable de entorno Path universal que no esté atada a un shell específico. Que te permita ejecutar comandos cd, lanzar python/git/cargo/aplicaciones arbitrarias, etc., y tener un buen sistema de marcadores + autocompletado. Parece que la confusión entre lenguaje de scripting + aplicación CLI es la raíz de estas complicaciones y sutilezas.
Si usas scripting de shell (y prefieres Bash etc. sobre Python), seguirías usando Bash/Fish/Zsh etc. Si usas la CLI para lanzar aplicaciones que no tienen GUI, navegar por directorios y realizar operaciones en el sistema de archivos, entonces usarías la terminal simple.
- ligarota
Solo crea un archivo ~ que sea un enlace simbólico al home :)
Momento de gran cerebro aquí