The VS Code SQLMesh extension assumes I am using bash or zsh #5608

Activity

1. StuffbyYuki

   added

   BugSomething isn't workingSomething isn't working

   Project: VSCode Extension

   on Jun 7, 2026
2. tripleaceme commented on Sep 24, 2026

   

   tripleaceme

   on Sep 24, 2026

   Contributor

   More actions

   I'd like to take this one if it's free — unassigned with no linked PR right now.

   The assumption is in vscode/extension/src/commands/printEnvironment.ts, which already branches on Windows:

   if (IS_WINDOWS) {
     terminal.sendText('set')
   } else {
     terminal.sendText('env | sort')
   }

   So the shape for handling this is already there; it just treats "not Windows" as "POSIX shell". My plan is to pick the command from the shell actually in use rather than from the platform, so fish gets set and bash/zsh keep env | sort.

   One question, since it changes how much this touches. VS Code exposes the configured default profile, but the terminal created here is a new one rather than the user's active terminal, so the reliable signal is what this extension asks VS Code to launch. Would you rather:

   1. detect the shell and choose the command, keeping it to this one file, or
   2. sidestep the shell entirely by printing the variables into an output channel or the terminal text directly, so no shell builtin is involved?

   I'd default to 1 as the smaller change, but 2 is more robust if you expect more shells to come up. Happy to go either way.
3. tripleaceme commented on Sep 24, 2026

   

   tripleaceme

   on Sep 24, 2026

   Contributor

   More actions

   Two findings while implementing this, both of which change what the change is actually for.

   1. env | sort does work in fish. fish has real pipes, and env and sort are ordinary binaries there, so the current command prints the environment correctly. This is an idiomatic-output complaint rather than a break: set in fish also lists fish's own shell variables and uses fish's formatting, which is what you would expect to see. Worth being clear about, so the change is not read as fixing a crash.

   2. The command really is broken on Windows, which the issue does not mention. In PowerShell, set is an alias for Set-Variable. With no arguments it does not print the environment — it prompts:

   Supply values for the following parameters:
   Name[0]:
   

   PowerShell is VS Code's default terminal on Windows, so sqlmesh: Print Environment has been unusable for most Windows users, not just fish users. I have fixed that in the same place, since it is the same decision, but it does widen this beyond the issue's text — say if you would rather it were split out.

   I should be straight about confidence on that second one: it follows from Set-Variable's documented behaviour, not from a run. I have no Windows or fish here, so I could not verify either end to end, and the replacement PowerShell command (Get-ChildItem Env: | Sort-Object Name) is likewise unverified against a live shell.

   On your choice between the two approaches I asked about — I have implemented option 1, detecting the shell, since it is the smaller change and gives you something concrete to react to. Having built it, I would argue for option 2. The extension already has the variables in hand as a JavaScript object; shelling out to ask the shell to print back what we just handed it is a round trip with no purpose, and the lookup table grows forever as nushell, xonsh, elvish and PowerShell-on-Linux turn up, each row untestable without that shell installed. Writing them into an output channel would be fewer lines than what I have now, identical on every shell and platform, and removes the whole class of bug.

   The one thing a terminal gives that an output channel does not is an interactive shell with the environment already loaded, which the user can then type into. If that is the intent, option 1 is right and option 2 is a regression. That is your call, and the PR is structured so switching is a deletion of one file and one import.