Is there a method to base a linked resource on an environment variable?

[gvl2023]

I know that linked resources can be created using internal Eclipse variables. Is it somehow possible to create a linked resource using a path that's contained in an environment variable?

[jukzi]

no - environment variables can change at runtime. you can use only theese constants:

[jukzi]

Dynamically Add/Edit Environment Variables of Remote Process
https://www.codeproject.com/Articles/32131/Dynamically-Add-Edit-Environment-Variables-of-Remo

[laeubi]

Well this is really nothing that qualifies ENV variables as "they can change dynamically"... I assume that there is actually no process out there that really assumes they change "dynamically"....

[gvl2023]

Seems like a wrong reason to omit a very useful feature if this is why there’s no support for env. variables out of the box.

[mickaelistria]

I think support for environment variables in linked resources path wouldn't be rejected if you contribute it.

[iloveeclipse]

Seems like a wrong reason to omit a very useful feature if this is why there’s no support for env. variables out of the box.

No one knows why that wasn't implemented at very beginning. May be the original authors of the code simply didn't assumed this as useful at all, because they were running on Windows and the environment variables were not so common in their own development. We don't know that anymore, because no one from original authors of the code is there.

But assuming there is a way to properly handle duplicated variables provided by different providers, one can add one default provider in IDE (may be guarded by an option) that would simply mirror all of the environment variables.

[iloveeclipse]

One can contribute custom path variable resolver, see https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_core_resources_variableResolvers.html

This one can simply mirror all environment variables.

Note: since the variables returned by resolver can be saved & used in project files, one should supply only variables that are "known to be stable" in the current environment.

[mickaelistria]

Debug allows ${env_var:PATH} or similar, Maven allows env.PATH... I would recommend someone who wants to contribute such variable resolver to use one of these prefix.

[laeubi]

You don't need to mirror all variables... a variable can be parameterized (see the "extend" button in the screenshot above) so one only needs ONE new ENV variable that takes the desired variable as a parameter.

[gvl2023]

Debug allows ${env_var:PATH} or similar, Maven allows env.PATH... I would recommend someone who wants to contribute such variable resolver to use one of these prefix.

Yup, I was going to suggest the same.

[merks]

One significant consideration is that if you checkin such a project with such links, how well does that work on another machine and/or even another OS?

[iloveeclipse]

This is a problem of people who use the variable, not of those who provide a variable, isn't?

[laeubi]

This is not really the concern of that function. Git itself support links, that only work on linux/mac but not on windows, different OS has different encodings, you can even at the moment parameterize the workspace loc with a random path in your workspace that must not be checked in anywhere, can be even DYNAMICALLY(!) deleted and so on ... there is so many things that can go wrong currently but still people are able to work together so I really don't think one should be over concerned here:

[merks]

Providing something that’s at best problematic to use certainly is not a ringing endorsement to providing it and is perhaps the reason it hasn’t been provided. I only mention this as something to consider, not as a reason to block this.