(Feature Request) Terminal Environment setting (like in VScode)

[Merith-TK]

Description of the new feature/enhancement

Arguments to the program. for example the ability to specify which mingw one would want to load, mingw64, mingw32, or msys2. like we can in VSCode

Proposed technical implementation details (optional)

This is accomplished in VSCode via this directive in settings.json

    "terminal.integrated.env.windows":
    {
        "MSYSTEM": "MINGW64",
        "CHERE_INVOKING":"1"
    },

My thougt process allowed something like

"commandlineEnv" : 
{
    "MSYSTEM" : "MINGW64"
},

In the settins.json file example. just like VSCode

Please do note, i know little to nothing about this language that this program is written in, so i don't know how difficult it would be to implement.

[zadjii-msft]

This is actually won't be terribly difficult to implement IMO. In ConhostConnection, we're already creating a EnvironmentVariableMapW with a WT_SESSION env var.

It wouldn't be impossible to also have another map of string->string key-value pairs that we also pass to the connection like this.

[Merith-TK]

Right now my current workaround is to use this .cmd file and ahve the terminal run that

set "MSYSTEM=MINGW64" 
C:/msys/usr/bin/bash.exe --login -i

[Merith-TK]

any progress? or is this put in the background with priority on bug fixes/better features? If so, i would understand.

[DHowett-MSFT]

Right now, we're focusing on bug fixes and features. You can check out our plans for October in the Terminal-1910 milestone, if you're interested. Right now, this one's sitting on the backlog ("not v1.0, but if we get some spare time we'll look at the features we've put off.")

That's not to say we don't care about this, of course. We'd be more than happy to review a pull request that adds support for this, so we've marked it Help-Wanted.

[DHowett-MSFT]

Thanks for asking!

[Merith-TK]

Ah! no worries! Sadly I know NOTHING about the lang this is being written in, so I cant be of any help here! I totally understand that! Functionality over features! Make the Program work, and THEN you add cool features (if that makes any sense)

[zadjii-msft]

Moving relevant discussion from #6604:

#6604

Following DHowett suggestion in #6585.

Description of the new feature/enhancement

For tools like MinGW you need certain environment variables to be set that define their behavior. It would be convenient to have these settings in the profile.

I suggest to add a property to the profile description in settings.json to set environment variables. For example

{
    "environment" : {
        "PATH": "c:/doomsday/emergency_commands/bin;${env:PATH}",
        "EMRGENCY_LEVEL_HIGH": "1"
    }
}

#6604 (comment)

If you have

{
    "environment" : {
        "HOMEDRIVE": "C:",
        "HOME": "${env:HOMEDRIVE}${env:HOMEPATH}",
        "HOMEPATH": "\\Users\\example"
    }
}

then should HOME use the original or new value of HOMEPATH? Should that depend on the lexical order of properties in the JSON object?

It might be easiest to implement this so that ${env:VAR} always means the original value, and the lexical order does not matter. If it becomes possible to define environment variables both globally and in each profile, then ${env:VAR} in a profile could refer to the value defined in the global environment object, and ${env:VAR} in the global environment could refer to the value received from Windows.

The syntax leaves room for adding ${new-env:VAR} with topological sorting later if needed.

[UndarkAido]

Is there any workaround for this? I'm trying to set up an SSH session with X forwarding. The environment variables get set weirdly when I do "commandline": "cmd /c \"set TMPDIR=C:\\Temp && set XAuthLocation=C:\\Progra~1\\VcXsrv\\xauth.exe && set DISPLAY=localhost:0 && ssh -X aidan@172.28.0.1\""

Edit: Remove the spaces before the &&s:
"commandline": "cmd /c \"set TMPDIR=C:\\Temp&& set XAuthLocation=C:\\Progra~1\\VcXsrv\\xauth.exe&& set DISPLAY=localhost:0&& ssh -X aidan@172.28.0.1\""

[christapley]

Hello @zadjii-msft, I would like to implement this feature. I'm still getting up to speed with your processes. Do you have any documentation on how you run your tests (specifically LocalTests_SettingsModel)?

[zadjii-msft]

That is a good question! I'm fairly certain that everyone on the team has a slightly different process but here's how I do it:

1. Open a new cmd.exe tab/pane
2. navigate to the directory the repo is in
3. run tools\razzle.cmd
4. then navigate to wherever the project you want to build is (in this case, cd src\cascadia\LocalTests_SettingsModel)
5. bx to build the project in this dicrectory
6. Then I use runut /name:*TestNameHere* to run the tests. The /name: arg lets you select tests to run based off the fully-qualified name. So if you wanted to run all the local tests for TSM, you could run runut /name:*SettingsModelLocalTests*. Or you could run a specific test with something like runut /name:*CanLayerColorScheme*. It's fairly flexible.

You only need to do steps 1-3 once. Once you have the "razzle" window set up, you can just keep switching to new directories and building them, you don't need to start a new window each time.

Lemme know if you need any other help. All the "Local" tests are a little weird, so I wouldn't be surprised if you ran into other issues ☺️

[christapley]

Thank you @zadjii-msft, I got the tests running.

[jacob-pro]

@Merith-TK A simple work around I am using for MSYS is to use env.exe to set environment variables like

C:\msys64\usr\bin\env.exe MSYSTEM=MINGW64 CHERE_INVOKING=1 /usr/bin/bash.exe --login

(msys2/msys2.github.io#215)

[volviq]

Is this features going to be implemented anytime soon?