Même si les liens symboliques sont résolus par le noyau, vous pouvez toujours faire une astuce LD_PRELOAD, en enveloppant toutes les fonctions libc qui prennent des noms de chemin et développent tous les composants $XYZ dans la chaîne renvoyée par 'readlink' (extension de paramètre). Ensuite, alimentez le chemin développé vers la fonction enveloppée. Vous devez échapper le chemin cible de l'expansion du shell lors de la création du lien, comme le suggère Jaztik.
Comme la bibliothèque injectée a un accès complet à l'environnement des utilisateurs, cela répondra à toutes les attentes de l'OP.
oui. aucun problème. en fait, vous n'utiliserez pas réellement la variable $HOME dans votre lien, donc cela ne fonctionnera pas avec des solutions intelligentes pour des groupes d'utilisateurs par exemple. La variable est traduite par le shell lors de l'exécution de la commande, et le contenu de la variable est utilisé dans le lien.
ln -s ~/test /tmp/test
est étendu à
/<path>/<to>/home/test -> /tmp/test
Ah. et seules les variables d'environnement de la personne appelant ln fonctionneront. Vous ne pouvez pas stocker les variables d'environnement d'autres personnes dans le lien. Les variables sont développées avant d'appeler la commande.
Si vous ne souhaitez pas développer la variable dans le lien, vous pouvez l'entourer de guillemets simples,
ln -s '$HOME/file/or/folder' newname
Cela donnerait,
newname -> $HOME/file/or/folder
plutôt que de l'étendre à votre $HOME défini localement. Comme décrit dans d'autres réponses, il ne le développera pas du tout. Ainsi, vous pouvez par ex. utilisez-le pour créer un lien symbolique vers un fichier à l'intérieur du littéral $HOME dossier.
[Notez que cela dépend du système - tous les systèmes ne prennent pas en charge les liens symboliques de variantes]
Les liens symboliques sont gérés par le noyau, et le noyau ne se soucie pas des variables d'environnement. Donc, non.