A pesar de que los enlaces simbólicos son resueltos por el kernel, aún podría hacer un truco LD_PRELOAD, envolviendo todas las funciones libc que toman nombres de ruta y expanden cualquier componente $XYZ en la cadena devuelta por 'readlink' (expansión de parámetros). Luego, alimente la ruta expandida a la función envuelta. Tienes que escapar de la ruta de destino de la expansión de shell al crear el enlace, como sugiere jaztik.
Como la biblioteca inyectada tiene acceso total al entorno de los usuarios, cumplirá todas las expectativas del OP.
sí. No hay problema. en realidad, no utilizará la variable $HOME en su enlace, por lo que no funcionará con soluciones inteligentes para grupos de usuarios, por ejemplo. El shell traduce la variable al ejecutar el comando, y el contenido de la variable se usa en el enlace.
ln -s ~/test /tmp/test
se expande a
/<path>/<to>/home/test -> /tmp/test
ah y solo funcionarán las variables de entorno de la persona que llama ln. No puede almacenar variables de entorno de otras personas en el enlace. Las variables se expanden antes de llamar al comando.
Si no desea expandir la variable en el enlace, puede poner comillas simples alrededor,
ln -s '$HOME/file/or/folder' newname
Esto daría,
newname -> $HOME/file/or/folder
en lugar de expandirlo a su $HOME configurado localmente. Como se describe en otras respuestas, no lo expandirá en absoluto. Entonces puedes, p. úselo para enlazar a un archivo dentro del literal $HOME carpeta.
[Tenga en cuenta que esto depende del sistema:no todos los sistemas admiten enlaces simbólicos variantes]
Los enlaces simbólicos son manejados por el kernel, y al kernel no le importan las variables de entorno. Entonces, no.