Vscode: Differentiate between user shell and automated shell

[joaomoreno]

As you might know, I use tmux as the default shell inside VS Code. This is something I'm not willing to give up since it allows me to restart VS Code and keep my shell session running. Giving that up would just make me use an external terminal and I want to keep selfhosting on the built-in terminal, cause it rocks.

This issue has hit me since I started with this setup (over 2 years): any feature which spawns a process on the terminal simply fails for my setup, since you can't spawn new shells on my setup. They all revert to the same shell: the tmux one. I can't run tasks. I can't start debug sessions with have pre launch tasks. Etc.

This means I always have to disable my custom shell in the settings every time I want to run a task (cc @alexr00) or launch a debug target (cc @isidorn). This has unconsciously and historically driven me away from using Tasks or Debug at all. I want to use both these two worlds.

@Tyriar A few options:

• Introduce a new setting which would allow me to specify a different shell for automated tasks (everything but "Open New Terminal")
• Introduce a new setting which would allow me to specify additional command line arguments when spawning automated tasks

[Tyriar]

@alexr00 @isidorn what are your thoughts on this? I think it ended up happening this way because users wanted to run their tasks/debug in their configured shell, but it can do some things that you don't want. It's similar to the interactive/non-interactive difference but tasks and debug are currently using interactive shells by design.

I know you can configure your shell in tasks.json, not sure about launch.json but this seems like a bad solution as you would need to check that in.

[isidorn]

I understand @joaomoreno bad experience and I think we should fix this.
@Tyriar can we at least provide a setting so the user can choose if the tasks/debug are run in their configured shell or not? Can you provide a pointer to the issue where users requested this behavior? Or at least was there passion that we do it the current way?

fyi @weinand

[alexr00]

I think it makes sense to have a new setting for the tasks shell (terminal.integrated.tasks.shell.*). If this setting is not set, we use the terminal.integrated.shell.* value. And, if the user overrides this value in any of their tasks then we respect that.

This is something that could be done entirely from the tasks side which is nice.

[alexr00]

Related(or duplicate): https://github.com/microsoft/vscode/issues/59789

[isidorn]

I just checked on @joaomoreno machine and it seems like running a debug session in the integrated terminal works fine with his shell.

So it seems that this could be fixed just from the tasks side as @alexr00 suggests

[Tyriar]

terminal.integrated.tasks.shell.*

@alexr00 I don't think we should be talking about tasks in the terminal settings.

I just checked on @joaomoreno machine and it seems like running a debug session in the integrated terminal works fince with his shell.

@joaomoreno doesn't your setup attach to an existing session, which may not be interactive at the time?

[joaomoreno]

Yes. I usually split tmux into two zones: yarn watch at the top and regular shell at the bottom. If focus happens to be on the top zone... then it won't work. Just verified this, @isidorn

[isidorn]

@joaomoreno thanks then this is common to just how we launch in a terminal and should not be a task setting. But a terminal one.
fyi @weinand

[Tyriar]

Would we break anyone if we just stopping using shellArgs in tasks and debug and only take the shell? Trying to use both would break scenarios like this https://github.com/microsoft/vscode/issues/59789

[alexr00]

There could be people who rely on the the shellArgs in tasks. I'd rather have a new setting that takes precedence over the terminal setting.

[Tyriar]

Any suggestions on a name for the setting that sums it up well? terminal.integrated.useShellArgsInIntegrations 😕

[alexr00]

task.shell.<os> and task.shellArgs.<os>?

[Tyriar]

@alexr00 it sounds like it needs to live in the terminal namespace though since debug also needs this.

[weinand]

@Tyriar I'm not sure that debug will make use of these settings.

There are two potential places in debug land where the new settings might be relevant:

• pre/postlaunch tasks: since we are using tasks as a (blackbox) service here, we will rely on Tasks to use the right setting. There is no need for introducing debug specific terminal settings for pre/postlaunch tasks.
• launching the debuggee in the integrated terminal. Is this the "user shell" or the "automated shell" case? I'm inclined to say that this is the "user shell" (which does not require new settings).

@joaomoreno Is my assumption correct?

[Tyriar]

I'm inclined to say that this is the "user shell" (which does not require new settings).

@weinand the problem is that @joaomoreno's is tmux and connects to an existing session which has multiple panes and the focused pane may or may not have something running inside it. Alternatively we could just say this is incompatible with debugging using the integrated terminal and just use the debug console instead?

[weinand]

@joaomoreno do you need another (debug specific) setting for debuggee launching in the integrated terminal?

[joaomoreno]

I'd love to keep using the Integrated Terminal even for debugging, since I can be debugging programs which take user input. So, I would wish for VS Code to use zsh in that case, instead of using my custom code-shell script which spawns tmux.

[alexr00]

@joaomoreno do you think you'd always want the same shell for debugging and for tasks?

[Tyriar]

@joaomoreno I don't think debug and tasks use terminal.integrated.env.*, so you could set some variable there to flag to your script that you're within a non-task/debug shell?

[Tyriar]

Ok I think I was wrong about that. How about terminal.integrated.useShellArgsForAutomation? Do we think shell args will be the only setting conflict problem we're going to run into?

[alexr00]

The shell too, not just the args. Is your thought that this would be a setting that only tasks reads?

[Tyriar]

@alexr00 what shell would tasks fallback to, just the default assuming terminal.integrated.shell.* was null?

[alexr00]

I was thinking we should allow the shell and args to be configurable for automation terminals. The terminal code wouldn't actually be reading the settings, but tasks and debug would:
terminal.integrated.automation.shell.*
terminal.integrated.automation.shellArgs.*

[Tyriar]

terminal.integrated.automation.env.* also? That's a lot of new settings

[alexr00]

@joaomoreno (correct me if I'm wrong) sets terminal.integrated.shell.osx to use tumx, so we need to have a setting that allows users to "escape" their tmux setup for tasks. Having a setting that disables the shellargs isn't enough.

I'm guessing that users who care enough about their terminal to use tmux also care about which shell is used for tasks, so making it configurable would be ideal. In general, you probably don't want to set shellArgs for automation related terminal use since I'd expect the automation to take care of that. We probably don't need a new shellArgs setting. If the user sets an terminal.integrated.automation.shell.*, then they get whatever args the automation uses.

Actually, users probably just want to remove their extra shellArgs when using automation, so setting terminal.integrated.automation.shell.* to remove the shellArgs would solve arguments problems too.

The env isn't really an issue here, so it's safe to keep doing what we're doing with it.

TLDR; Just terminal.integrated.automation.shell.* ?

[Tyriar]

See https://medium.com/@joaomoreno/persistent-terminal-sessions-in-vs-code-8fc469ed6b41 for the setup:

"terminal.integrated.shell.osx": "/Users/joao/bin/code-shell"

5 names in a setting is quite a bit, would terminal.integrated.automationShell be better? 🤔

[alexr00]

terminal.integrated.automationShell.* SGTM. @Tyriar I think it would be simplest to read this in tasks rather than terminal. Do you have a preference?

[Tyriar]

@alexr00 debug needs to use it so it should live in the terminal namespace

[Tyriar]

@joaomoreno try out terminal.integrated.automationShell.* in the next build

[Tyriar]

There was some feedback in stand up about it being a bit confusing what the purpose of the setting was, so suggestions on the setting name and description are welcome. What are your thoughts on adding examples of why you would want to use (eg. running powershell with a different profile, avoiding a complicated shell setup).

[joaomoreno]

@Tyriar I have set up:

    "terminal.integrated.automationShell.linux": "/usr/bin/zsh",

When I F5 an extension, I get this and no terminal appears open:

[Tyriar]

@joaomoreno can you launch /usr/bin/zsh in an external terminal?

[joaomoreno]

Yep that works:

    "terminal.integrated.shell.linux": "/usr/bin/zsh"

[Tyriar]

@joaomoreno can you turn on trace logging and trigger the error? The logs will say the environment, shell and shell args used. That might lead to the answer

[joaomoreno]

[2019-08-13 16:09:15.879] [renderer3] [trace] onWillActivateByEvent:  onCommand:workbench.action.tasks.runTask
[2019-08-13 16:09:15.890] [renderer3] [trace] terminalInstance#ctor (id: 1) {"name":"Task - watch","executable":"/usr/bin/zsh","args":["-c","npm run watch"],"waitOnExit":false,"initialText":"\u001b[1m> Executing task: npm run watch <\u001b[0m\n","cwd":{"$mid":1,"path":"/home/joao/Work/banana","scheme":"file"}}
[2019-08-13 16:09:15.908] [renderer3] [trace] IPty#spawn /usr/bin/zsh ["-c","npm run watch"] {"name":"xterm-256color","cwd":"/home/joao/Work/banana","env":{"CLUTTER_IM_MODULE":"xim","LC_MEASUREMENT":"en_US.UTF-8","LC_PAPER":"en_US.UTF-8","LC_MONETARY":"en_US.UTF-8","LANG":"en_US.UTF-8","DISPLAY":":1","DISABLE_WAYLAND":"1","USERNAME":"joao","CHROME_DESKTOP":"code-insiders-url-handler.desktop","NO_AT_BRIDGE":"1","XDG_VTNR":"2","SSH_AUTH_SOCK":"/run/user/1000/keyring/ssh","MANDATORY_PATH":"/usr/share/gconf/i3.mandatory.path","APPLICATION_INSIGHTS_NO_DIAGNOSTIC_CHANNEL":"true","LC_NAME":"en_US.UTF-8","XDG_SESSION_ID":"3","USER":"joao","DESKTOP_SESSION":"i3","QT4_IM_MODULE":"xim","DEFAULTS_PATH":"/usr/share/gconf/i3.default.path","PWD":"/home/joao","HOME":"/home/joao","QT_ACCESSIBILITY":"1","XDG_SESSION_TYPE":"x11","XDG_DATA_DIRS":"/home/joao/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share/:/usr/share/i3:/home/joao/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop","GSETTINGS_SCHEMA_DIR":"/snap/code-insiders/221/usr/share/glib-2.0/schemas","XDG_SESSION_DESKTOP":"i3","LC_ADDRESS":"en_US.UTF-8","LC_NUMERIC":"en_US.UTF-8","GDK_PIXBUF_MODULE_FILE":"/home/joao/snap/code-insiders/common/.cache/gdk-pixbuf-loaders.cache","GTK_MODULES":"gail:atk-bridge","PAPERSIZE":"letter","WINDOWPATH":"2","SHELL":"/usr/bin/zsh","QT_IM_MODULE":"ibus","XMODIFIERS":"@im=ibus","IM_CONFIG_PHASE":"2","XDG_CURRENT_DESKTOP":"i3","GPG_AGENT_INFO":"/run/user/1000/gnupg/S.gpg-agent:0:1","BAMF_DESKTOP_FILE_HINT":"/var/lib/snapd/desktop/applications/code-insiders_code-insiders.desktop","XDG_SEAT":"seat0","SHLVL":"2","GDK_PIXBUF_MODULEDIR":"/snap/code-insiders/221/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders","LC_TELEPHONE":"en_US.UTF-8","GDMSESSION":"i3","XDG_CACHE_HOME":"/home/joao/snap/code-insiders/common/.cache","LOGNAME":"joao","DBUS_SESSION_BUS_ADDRESS":"unix:path=/run/user/1000/bus","XDG_RUNTIME_DIR":"/run/user/1000/snap.code-insiders","XAUTHORITY":"/run/user/1000/gdm/Xauthority","XDG_CONFIG_DIRS":"/etc/xdg/xdg-i3:/etc/xdg","PATH":"/home/joao/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin","LC_IDENTIFICATION":"en_US.UTF-8","GTK_IM_MODULE":"ibus","LC_TIME":"en_US.UTF-8","_":"/snap/code-insiders/221/usr/share/code-insiders/bin/../code-insiders","VSCODE_TMUX":"true","TERM_PROGRAM":"vscode","TERM_PROGRAM_VERSION":"1.38.0-insider","COLORTERM":"truecolor"},"cols":0,"rows":0,"experimentalUseConpty":false,"conptyInheritCursor":false}
[2019-08-13 16:09:16.413] [renderer3] [debug] Terminal process ready (shellProcessId: 19455)
[2019-08-13 16:09:16.416] [renderer3] [trace] IPty#kill
[2019-08-13 16:09:16.416] [renderer3] [debug] Terminal process exit (id: 1) with code 127
[2019-08-13 16:09:16.416] [renderer3] [debug] Terminal process exit (id: 1) state 5
[2019-08-13 16:09:16.416] [renderer3] [trace] terminalInstance#dispose (id: 1)

Thanks!

[Tyriar]

Does changing to sh or bash help? 127 might mean that npm couldn't be found? https://stackoverflow.com/a/1763178/1156119

Where is npm added to your path?

[NSExceptional]

@Tyriar / @alexr00 Is terminal.integrated.automationShell in an insiders build I can try yet?

[alexr00]

Yes it is in insiders!

[joaomoreno]

@Tyriar I think you are right! My issue now stems from https://github.com/microsoft/vscode/issues/72042

Thanks for the setting, it does work! I'll push https://github.com/microsoft/vscode/issues/72042 ahead to get that fixed.

[joaomoreno]

@Tyriar Thanks for this, I can (and do!) now easily selfhost on:

• Tasks @alexr00
• Problems @sandy081
• Debug @isidorn