Moderately complex commandline property in profiles.json stopped working #4955

Closed
opened 2026-01-31 00:01:30 +00:00 by claunia · 6 comments
Owner

Originally created by @rbeesley on GitHub (Nov 13, 2019).

Environment

Windows Terminal (Preview)
Version: 0.6.3121.0
PS C:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.19018.1
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19018.1
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
PS C:\> conda --version
conda 4.7.12

Steps to reproduce

  1. Install Anaconda
  2. Create a profile in profiles.json which is the same as the following, with updated references where needed:
// profiles.json

{
   "profiles":
    [
        {
            "guid": "{398546a1-6641-4b31-b81d-2afca23ddc5f}",
            "icon": "ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png",
            "hidden": false,
            "name": "Anaconda Powershell Prompt (current)",
            "startingDirectory": "%HOMEPATH%",
            "commandline": "%windir%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -ExecutionPolicy ByPass -NoExit -Command \"& 'C:\\Users\\[REDACTED]\\scoop\\apps\\anaconda3\\current\\shell\\condabin\\conda-hook.ps1' ; conda activate 'C:\\Users\\[REDACTED]\\scoop\\apps\\anaconda3\\current' \""
        },
    ],
}
  1. Try to launch launch this profile in Terminal

Expected behavior

This same profile had been used to launch an Anaconda Powershell Prompt and until Terminal v0.6.3121.0, had been working properly.

Actual behavior

Now, there is a brief flash where it seems like Terminal is trying to launch the shell, but it quickly fails to do so and closes that tab. If I launch a regular PowerShell shell, and then manually issue the Command, I can get things working as they previously did, so this seems to be a recent change with how the commandline property is read rather than what I'm trying to execute. This seems to have stopped working with the update I received from Microsoft Store recently. Microsoft Store indicates that I received an update yesterday, but I can't confirm that this was when this change occurred, only that it happened in the past few days as this was working last week. I am suspicious that there was a change with how escaping things might have changed but I wasn't able to determine what is different now and what might work.

Originally created by @rbeesley on GitHub (Nov 13, 2019). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> <!-- This bug tracker is monitored by Windows Terminal development team and other technical folks. **Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue. If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link. Please use this form and describe your issue, concisely but precisely, with as much detail as possible. --> # Environment ```none Windows Terminal (Preview) Version: 0.6.3121.0 ``` ```none PS C:\> $PSVersionTable Name Value ---- ----- PSVersion 5.1.19018.1 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.19018.1 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1 ``` ```none PS C:\> conda --version conda 4.7.12 ``` # Steps to reproduce <!-- A description of how to trigger this bug. --> 1. Install Anaconda 2. Create a profile in `profiles.json` which is the same as the following, with updated references where needed: ```json // profiles.json { "profiles": [ { "guid": "{398546a1-6641-4b31-b81d-2afca23ddc5f}", "icon": "ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png", "hidden": false, "name": "Anaconda Powershell Prompt (current)", "startingDirectory": "%HOMEPATH%", "commandline": "%windir%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -ExecutionPolicy ByPass -NoExit -Command \"& 'C:\\Users\\[REDACTED]\\scoop\\apps\\anaconda3\\current\\shell\\condabin\\conda-hook.ps1' ; conda activate 'C:\\Users\\[REDACTED]\\scoop\\apps\\anaconda3\\current' \"" }, ], } ``` 3. Try to launch launch this profile in Terminal # Expected behavior <!-- A description of what you're expecting, possibly containing screenshots or reference material. --> This same profile had been used to launch an Anaconda Powershell Prompt and until Terminal v0.6.3121.0, had been working properly. # Actual behavior <!-- What's actually happening? --> Now, there is a brief flash where it seems like Terminal is trying to launch the shell, but it quickly fails to do so and closes that tab. If I launch a regular PowerShell shell, and then manually issue the Command, I can get things working as they previously did, so this seems to be a recent change with how the commandline property is read rather than what I'm trying to execute. This seems to have stopped working with the update I received from Microsoft Store recently. Microsoft Store indicates that I received an update yesterday, but I can't confirm that this was when this change occurred, only that it happened in the past few days as this was working last week. I am suspicious that there was a change with how escaping things might have changed but I wasn't able to determine what is different now and what might work.
claunia added the Resolution-Duplicate label 2026-01-31 00:01:30 +00:00
Author
Owner

@DHowett-MSFT commented on GitHub (Nov 13, 2019):

Good news! This was #3548, and an update was published to the selfhost channel that fixed it.

@DHowett-MSFT commented on GitHub (Nov 13, 2019): Good news! This was #3548, and an update was published to the selfhost channel that fixed it.
Author
Owner

@DHowett-MSFT commented on GitHub (Nov 13, 2019):

/dup #3548

@DHowett-MSFT commented on GitHub (Nov 13, 2019): /dup #3548
Author
Owner

@ghost commented on GitHub (Nov 13, 2019):

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@ghost commented on GitHub (Nov 13, 2019): Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Author
Owner

@rbeesley commented on GitHub (Nov 13, 2019):

Seems like it could be related to #3198. I created a new profile, with different GUID, kept everything else the same, but replaced the Environment variables in the profile with their expanded replacements. This allows the new profile to open as before, but with hard-coded paths.

The reason this might not be the change which broke this behavior for me, is that it says this change was in v0.6.2951.0 and I think this might have been the build I had before where this was working. Still looking at changes, but it seems very likely that a problem with environment variable expansion is the root.

@rbeesley commented on GitHub (Nov 13, 2019): Seems like it could be related to #3198. I created a new profile, with different GUID, kept everything else the same, but replaced the Environment variables in the profile with their expanded replacements. This allows the new profile to open as before, but with hard-coded paths. The reason this might not be the change which broke this behavior for me, is that it says this change was in v0.6.2951.0 and I think this might have been the build I had before where this was working. Still looking at changes, but it seems very likely that a problem with environment variable expansion is the root.
Author
Owner

@rbeesley commented on GitHub (Nov 13, 2019):

Looks like it might be a duplicate of #3548. I think this might be fixed.

@rbeesley commented on GitHub (Nov 13, 2019): Looks like it might be a duplicate of #3548. I think this might be fixed.
Author
Owner

@rbeesley commented on GitHub (Nov 13, 2019):

@DHowett-MSFT, I should have refreshed my bug report page... I just saw that fix in the changes and presumed it to be the same issue when reading the bug, so I didn't see that you had already resolved this when I was commenting.

@rbeesley commented on GitHub (Nov 13, 2019): @DHowett-MSFT, I should have refreshed my bug report page... I just saw that fix in the changes and presumed it to be the same issue when reading the bug, so I didn't see that you had already resolved this when I was commenting.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#4955