vscode-remote-release
vscode-remote-release copied to clipboard
open in dev container pop up uses wrong terminal
Version: 1.68.1 Commit: 30d9c6cd9483b2cc586687151bcbcd635f373630 Date: 2022-06-15T02:58:26.441Z Electron: 17.4.7 Chromium: 98.0.4758.141 Node.js: 16.13.0 V8: 9.8.177.13-electron.0 OS: Linux x64 5.10.102.1-microsoft-standard-WSL2 snap
Steps to Reproduce:
- Configure your terminal settings to use
bash - Open a folder/project that contains a dev container
- Click the pop up that asks if you want to open the workspace inside the dev container
- The terminal will default to
shinstead ofbash.
This only happens when you use the gui pop up? If I use ctrl-shift-p and "rebuild and reopen" or "reopen in container" then the terminal will open in bash?
I have noticed this issue for a while now? Months? So I thought I would open a ticket for it.
Does this issue occur when you try this locally?: Yes Does this issue occur when you try this locally and all extensions are disabled?: I would guess so, I dont think any extensions are running in the devcontainer.
Does this issue belong here or https://github.com/microsoft/vscode-dev-containers
Could you share your user settings and your devcontainer.json?
You can have settings in the devcontainer.json when they need to be different from your local settings.
It is happening across many of my dev containers and it seems to be random. Also it happens even if you use the command palette not just the pop up.
devcontainer.json
// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.231.2/containers/ubuntu
{
"name": "${localWorkspaceFolderBasename}",
"build": {
"dockerfile": "Dockerfile"
},
// Set *default* container specific settings.json values on container create.
"settings": {
"terminal.integrated.profiles.linux": {
"bash": {
"path": "/usr/bin/bash",
"icon": "terminal-bash"
}
},
"terminal.integrated.defaultProfile.linux": "bash"
},
// Add the IDs of extensions you wantinstalled when the container is created.
"extensions": [
],
// Use 'forwardPorts' to make a list of ports inside the container available locally.
// "forwardPorts": [],
// Use 'postCreateCommand' to run commands after the container is created.
// "postCreateCommand": "cd tests && go mod init ${localWorkspaceFolderBasename} || true",
"postStartCommand": "echo hello",
// Comment out to connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
"remoteUser": "vscode"
}
My personal settings.json
{
"git.confirmSync": false,
"git.autofetch": true,
"files.autoSave": "onFocusChange",
"files.exclude": {
"**/.terraform": true,
"**/node_modules": true,
"**/.classpath": true,
"**/.project": true,
"**/.settings": true,
"**/.factorypath": true
},
"diffEditor.ignoreTrimWhitespace": false,
"[python]": {
"editor.insertSpaces": true,
"editor.tabSize": 4,
"editor.detectIndentation": false
},
"[groovy]": {
"editor.tabSize": 4,
"editor.insertSpaces": true,
"editor.detectIndentation": false
},
"terminal.integrated.allowChords": false,
"groovy.classpath": [
"/home/shadycuz/repos/dsty/jenkins-std-lib/build/dependencies"
],
"files.trimTrailingWhitespace": true,
"[markdown]": {
"files.trimTrailingWhitespace": false
},
"editor.guides.bracketPairs": true,
"editor.bracketPairColorization.enabled": true,
"workbench.sideBar.location": "right",
"diffEditor.renderSideBySide": false,
"[dockerfile]": {
"editor.defaultFormatter": "ms-azuretools.vscode-docker"
},
"explorer.confirmDelete": true,
"shellcheck.customArgs": [
"-x"
],
"terminal.integrated.fontFamily": "'MesloLGM Nerd Font Mono'",
"git.commandsToLog": [
"commit"
]
// "groovy.java.home": "/usr/bin/java",
// "groovy.trace.server": "verbose"
}
Dockerfile
FROM ubuntu:22.04
ARG USERNAME=vscode
ARG USER_UID=1000
ARG USER_GID=$USER_UID
# Ensure apt is in non-interactive to avoid prompts
ENV DEBIAN_FRONTEND=noninteractive
# Create the user
RUN groupadd --gid $USER_GID $USERNAME \
&& useradd --uid $USER_UID --gid $USER_GID -m $USERNAME \
#
# [Optional] Add sudo support. Omit if you don't need to install software after connecting.
&& apt-get update \
&& apt-get install -y sudo \
&& echo $USERNAME ALL=\(root\) NOPASSWD:ALL > /etc/sudoers.d/$USERNAME \
&& chmod 0440 /etc/sudoers.d/$USERNAME
ENV DEBIAN_FRONTEND=dialog
USER $USERNAME
ENV HOME /home/$USERNAME
WORKDIR $HOME
@chrmarti So while coming up with a minimal reproducible example, I realised just how hard it is to trigger this issue, its very intermittent.
Sometimes I see:

and when I hit any key, the entire terminal window closes and I have to hit ctrl + j to reopen it and when I do, I'm in bash like it was expected.
But sometimes... I see this:
See that sh tab? I dont know where it comes from. But pressing any key wont close the terminal... It will close the current tab and drop me into the sh, instead of bash.
After pressing any key:

This is the bug ^.
I'm pretty sure to trigger this bug you have to click "starting dev container (show log)". You also need a postStart command?
Here is my reproducible steps:
- From your local workspace (not inside the devcontainer). Use command palette to "Remote-Containers: Rebuild without cache and reopen in container".
- Click the "Starting Dev container (show log)" pop up.
- Your screen will look like this:

- Press any key and your screen will look like this:

- Now use command palette to "Remote-Containers: Rebuild containers" but this time dont click on "show log".
- If you have the
shtab and your screen looks like this:
Then the bug was triggered. If not you have to start over again at step 1. It is very intermittent. I also know that this isn't the only way to randomly get a sh tab hanging around that trigger this bug. But once you see the sh tab, you can press any key to be dropped into sh:

Then you have to type exit to close it and ctrl + j to reopen a new terminal in bash.

After experimenting while trying to reproduce, I would rephrase the issue as "devcontainer intermittently opens a sh tab while building/reopening devcontainers"
EDIT: I actually have found this to be reproducible without the intermittent part.
- Open a devcontainer with any method you would like but make sure you hit "view logs"
- Rebuild/reopen the same container but dont click "view logs".
- You are now in
shinstead ofbash.
I am experiencing the exact same thing, but instead of sh, the extra tab is running zsh, but without any of the settings defined in zshrc and profile applied. Oddly enough, if I click on See logs things work as expected.
@chrmarti It isn't an issue with my local machine, which I had thought it might be.
This happens on my machine too, but it only occurs after a build / rebuild if I don't wait long enough.
Hey @chrmarti, this issue might need further attention.
@shadycuz, you can help us out by closing this issue if the problem no longer exists, or adding more information.
Still exists. Not sure I can descibe the behavior any better than I already did. Most of the time, after building or opening a devcontainer, I am left at a sh instead of bash.
This happens on my machine too, but it only occurs after a build / rebuild if I don't wait long enough.
This report of mine is still accurate.
It is as if the user-defined shell setting or the shell itself hasn't loaded yet and the system is falling back to the default (sh).
I actually have found this to be reproducible without the intermittent part.
- Open a devcontainer with any method you would like but make sure you hit "view logs"
- Rebuild/reopen the same container but dont click "view logs".
- You are now in
shinstead ofbash.
No luck trying to reproduce this. It must be a timing related issue. Does it work with a simplified setup:
{
"image": "ubuntu:22.04",
"settings": {
"terminal.integrated.profiles.linux": {
"bash": {
"path": "/usr/bin/bash",
"icon": "terminal-bash"
}
},
"terminal.integrated.defaultProfile.linux": "bash"
},
"postStartCommand": "echo hello"
}
Do you have a .vscode/settings.json in your workspace folder?
I actually have found this to be reproducible without the intermittent part.
- Open a devcontainer with any method you would like but make sure you hit "view logs"
- Rebuild/reopen the same container but dont click "view logs".
- You are now in
shinstead ofbash.No luck trying to reproduce this. It must be a timing related issue. Does it work with a simplified setup:
{ "image": "ubuntu:22.04", "settings": { "terminal.integrated.profiles.linux": { "bash": { "path": "/usr/bin/bash", "icon": "terminal-bash" } }, "terminal.integrated.defaultProfile.linux": "bash" }, "postStartCommand": "echo hello" }Do you have a
.vscode/settings.jsonin your workspace folder?
If I recall correctly, you'd be able to reproduce it if you moved the "terminal.integrated.defaultProfile.linux" to the global settings.json.
I am experiencing this issue on Ubuntu Arm64 22.04 host. Is there a (hack) to change the default shell from sh to bash as a workaround?
@evbo Please append your container log (F1 > Dev Containers: Show Container Log), devcontainer.json and terminal settings in your user settings.
@chrmarti
"terminal.integrated.scrollback": 100000,
"terminal.integrated.profiles.linux": {
"bash": {
"path": "/bin/bash"
}
},
"terminal.integrated.defaultProfile.linux": "bash",
Also, when it first loads a sh shell is started. But anytime I manually close it and select new terminal the correct bash shell is started.
@chrmarti (and everyone bothered by this issue) I thought of probably the simplest workaround IF you have permission to change the docker image:
# where USERNAME is (hopefully) a non-root user (don't run docker containers as root!)
chsh --shell /bin/bash ${USERNAME}
Works on Ubuntu by changing the system's default shell! But this does require root so you can't run this command anywhere else other than in the Dockerfile.
Are the settings you posted from the user settings (Ctrl + .) or from the devcontainer.json?
thanks but they are identical in both
Adding back this deprecated setting fixed it for my PowerShell environment.

I'm having the same problem. My only current workaround would be setting the default shell in the Dockerfile instead of the devcontainer.json. That's however only possible for projects that own the Dockerfile.
If you are affected by this issue still, please upvote the first comment. This will help show the project maintainers the impact this issue has.
Hey @Tyriar @meganrogge, this issue might need further attention.
@shadycuz, you can help us out by closing this issue if the problem no longer exists, or adding more information.
I used to have this issue, but not anymore.