login shell in integrated terminal stopped working on 1.75.0

[bluebrown]

Does this issue occur when all extensions are disabled?: Yes/No

• VS Code Version: 1.75.0
• OS Version: Linux WDE-N-W0410 5.15.79.1-microsoft-standard-WSL2 x86_64 GNU/Linux

Steps to Reproduce:

After updating vscode to 1.75.0, yesterday. The below config is not working anymore. Before that, I would get my configurations bound to running a login shell.

  "terminal.integrated.profiles.linux": {
        "bash": {
            "path": "bash",
            "icon": "terminal-bash",
            "args": [
                "-l"
            ]
        },
    },

Particularly, I use starship and have set this in ~/.bash_login. But my prompt is not using starship in vscode anymore.

cat ~/.bash_login 
#!/usr/bin/env bash

if [ -f "$HOME/.bashrc" ]; then
  . "$HOME/.bashrc"
fi

eval "$(starship init bash)"

eval "$(direnv hook bash)"

[meganrogge]

Pretty sure this hasn't changed recently - for bash login shells, the bash_profile will be run if it exists instead of bash_login. So you probably have a bash_profile that's getting run. Removing that will cause the bash_login file to be executed.

[bluebrown]

@meganrogge, I am sure that it was still working the minute before I closed VSCode, and it ran the auto update. When I opened vscode the next time, it didn't work anymore.

There is also no bash_profile. It also wouldn't pair well with the fact that my bash_login is indeed used, except for the in VsCodes integrated terminal. If that wasn't the case, I would not open the issue specifically with VS Code.

find ~ -maxdepth 1 -type f -name .bash_profile 
# wow such empty

I would appreciate if that could be opened again.

[bluebrown]

Hm, I just noticed that it works when I click explicitly on the bash terminal to open a terminal.

So it appears to be linked to the default terminal. It does not work when I simply click the plus icon or drag the lower edge of the editor up.

This is from the plus icon:

And this is from using explicit bash:

By explicit bash, I mean the entry in the dropdown

If you look closely, you see that the icons are also different for both terminal in the split. If I hover over them, both say the same thing. Bash - Shell integrated (active).

[bluebrown]

It is working now after selecting the default terminal profile.

Now the bash shell is also showing that it is the default in the dropdown

The strange part is, I do not have any other bash in the selection. So what was the default even set to?

[meganrogge]

cannot reproduce even when I delete my default profile.

[Tyriar]

@bluebrown does this only happen when you open the terminal panel, close the window and reopen it such that the panel gets "restored"? There have been bugs in the past around the first shell launched when the panel gets restored after startup.

[bluebrown]

@Tyriar, before I set my default terminal, it would not work at all. Now, since I have the default terminal set, it behaves like you describe. When I open a new VS Code window, it's still using the "wrong" bash. I need to close the terminal and open a fresh one, for the login shell to work.

[sfsaccone]

At the same time this issue appeared for me, in the Jan 2023 update, I also found that terminals take a much longer time to open and that there's a node process under heavy load. Should I open a new issue for this, or could it be related to this issue?

2023-03-03 edit: seems to be fixed in 1.76.

[ghost]

I'm seeing similar behavior to @bluebrown. When I reconnect to a Remote SSH host that had open integrated terminal tabs, they are re-opened as the built-in bash terminal profile, even though I have terminal.integrated.defaultProfile.linux set to a custom fish shell profile on this machine. Closing the tab and re-opening a new integrated terminal correctly picks my custom fish profile. This started after the Jan 2023 update.

(It's quite possible that the Remote SSH reconnection is unrelated, but that's the only place I re-open windows with integrated terminal tabs like this regularly.)

[Garfield550]

I use PowerShell as a login shell on Linux, as described in the Microsoft documentation, ‘On Linux and macOS, starts PowerShell as a login shell, using /bin/sh to execute login profiles such as /etc/profile and ~/.profile.’

> cat ~/.profile
if [ -f "$HOME/.cargo/env" ]; then . "$HOME/.cargo/env"; fi
if [ -d "$HOME/.local/share/fnm" ]; then export PATH="$HOME/.local/share/fnm:$PATH"; fi

When I access my Linux using any terminal emulator via the ssh command, .profile is executed and PATH behaves normally.

> $env:PATH
/run/user/1000/fnm_multishells/159305_1680016851874/bin:/opt/microsoft/powershell/7:/home/garfield/.local/share/fnm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

However, when I use VSCode Remote SSH to connect to my Linux and open VSCode’s Integrated Terminal, I observe that .profile is not executed and PATH is not modified.

> $env:PATH
/opt/microsoft/powershell/7:/home/garfield/.vscode-server/bin/ee2b180d582a7f601fa6ecfdad8d9fd269ab1884/bin/remote-cli:/opt/microsoft/powershell/7:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

As you can see, the PATH of the Powershell in VSCode Integrated Terminal does not include /run/user/1000/fnm_multishells/159305_1680016851874/bin and /home/garfield/.local/share/fnm.

[connor4312]

What's the best way to verify this? I made an executable ~/.bash_login file with the contents

#!/usr/bin/env bash
echo 'hi'

but I don't see "hi" being echo'ed.

[meganrogge]

@connor4312 add something to your ~/.bash_profile such as echo login and verify you see that

[tigerinus]

I am still experiencing this issue under SSH Remote from Windows to Linux (ubuntu)

I have following settings in both host and remote, but it doesn't seem to be effective. I have to manually run bash --login for each terminal session.

    "terminal.integrated.profiles.linux": {
        "bash": {
            "path": "bash",
            "args": [
                "--login"
            ],
            "icon": "terminal-linux",
        }
    },

@meganrogge which version is this issue fixed?

Version: 1.78.2 (user setup)
Commit: b3e4e68a0bc097f0ae7907b217c1119af9e03435
Date: 2023-05-10T14:39:26.248Z
Electron: 22.5.2
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Windows_NT x64 10.0.19045
Sandboxed: No