Anche se i collegamenti simbolici sono risolti dal kernel, puoi comunque eseguire un trucco LD_PRELOAD, avvolgendo tutte le funzioni libc che accettano percorsi ed espandono qualsiasi componente $XYZ nella stringa restituita da 'readlink' (espansione parametro). Quindi inserisci il percorso espanso nella funzione di cui è stato eseguito il wrapping. Devi sfuggire al percorso di destinazione dall'espansione della shell durante la creazione del collegamento, come suggerisce jaztik.
Poiché la libreria inserita ha pieno accesso all'ambiente degli utenti, ciò soddisferà tutte le aspettative dell'OP.
sì. nessun problema. in realtà non utilizzerai effettivamente la variabile $HOME nel tuo collegamento, quindi non funzionerà con soluzioni intelligenti per gruppi di utenti, ad esempio. La variabile viene tradotta dalla shell durante l'esecuzione del comando e il contenuto della variabile viene utilizzato nel collegamento.
ln -s ~/test /tmp/test
viene espanso in
/<path>/<to>/home/test -> /tmp/test
Ah. e funzioneranno solo le variabili d'ambiente della persona che chiama ln. Non è possibile memorizzare variabili di ambiente di altre persone nel collegamento. Le variabili vengono espanse prima di chiamare il comando.
Se non vuoi espandere la variabile nel link, puoi racchiuderla tra virgolette singole
ln -s '$HOME/file/or/folder' newname
Questo darebbe,
newname -> $HOME/file/or/folder
piuttosto che espanderlo nella tua $HOME impostata localmente. Come descritto in altre risposte, non lo espanderà affatto. Quindi puoi ad es. usalo per creare un collegamento simbolico a un file all'interno del letterale $HOME cartella.
[Nota che questo dipende dal sistema - non tutti i sistemi supportano i collegamenti simbolici delle varianti]
I collegamenti simbolici sono gestiti dal kernel e il kernel non si preoccupa delle variabili d'ambiente. Quindi no.