I am not a Visual Studio user, but standard JSON does not support variables. You would have to use some work-around importing the file and then stringifying and expanding it or having bash expand it in a here document or some work-around normally. Perhaps Visual Studio runs the file through a preprocessor or has some other work-around built in so I cannot say there is not a ready solution, but pure standard JSON would need expanded names.
I had a similar issue when dealing with VSCode gfortran on Windows but it didn’t seem to be an issue on WSL. I can’t remember if I did anything different.
Are you using Windows? I had issues with Windows vs Linux paths. Maybe the variables contain Windows style paths. Does it work if you change the hard-coded portion to Windows? Remember to double the backslashes.
Unfortunately, it seems that
”fortran.linter.compilerPath”:”${env:HOME}/.local/bin/gfortran”
does not work, while “fortran.fortls.path” does.
It seems the problem is in the Modern Fortran extension handling of the settings entry. If I expand ${env:HOME} explicitly, it works.
Looking at the Modern Fortran extension in github, it seems (I am not familiar with the VSCode extensions API) that it is reading the json attributes literally,
Looking into the handling for the language server path, fortls, which works, it seems it is missing the resolution of the variables in the string via a ResolveVariables (from util/tools) call
It would be great to “resolve those environment variables”